J'ai un portable dont l'écran a de gros mauvais contact (un coup plus rien, un coup plein de lignes de couleurs ..). Bon, 4 ans ces jours-ci, beaucoup trimbalé à une époque ...
Aucune idée du prix actuel, mais à une époque, je les avais vu sur le site Toshiba : presque le prix d'un portable neuf !
Mais heureusement, ça peut toujours se recycler soit un PC ordinaire en branchant écran+clavier+souris externes, soit en serveur de ce qu'on veut en réseau (plus besoin d'écran).
Bon, depuis l'autre jour, j'ai essayé de lancer SSH en mode debug/bavard (serveur et client), sans que ça ne m'aide.
Ce matin, j'ai encore eu le problème, mais ethereal a bien voulu marché. En fait, c'est au niveau ARP que ça coince. Le PC neuf demande en broadcast quelle est l'adresse ethernet correspondant à l'IP du vieux micro. L'ethereal du vieux voit partir la réponse, mais sur le neuf, on ne voit pas cette réponse. Bizarre ... Je vais donc voir comment débuger ça.
Pour l'ethereal qui gèle en local, ce n'est peut être qu'une coïncidence, mais je l'ai mentionné au cas où, car je ne l'ai vu geler que dans cette circonstance.
Si je comprends bien, il n'y a donc plus de problème de compatibilité.
Si toutes les distros étaient exactement pareils, ça servirais a quoi d'en avoir plusieurs ?
Comme je l'ai déjà dis ailleurs, les développeurs développent chacun de leur coté, en ne fournissant que les sources, et de manière complètement asynchrone par rapport aux soft/bibliothèques qu'ils utilisent. Je serais donc comme beaucoup incapables d'aller chercher de tous les cotés tout les sources de tout ce qui est sur mon micro (des briques de bases jusqu'aux grosses applis) et de réussir à faire marcher le tout ensemble.
C'est là que les distribs ont leur place : faire une sélection cohérente de sources (par rapport aux dépendances), faire le travail de compilation, et fournir un outil d'installation/gestion des paquets.
Pourquoi plusieurs distribs ? Parce qu'on peut gérer ça de différentes manières :
- Mandrake cherche à avoir des trucs récents (instables selon certains), et très facile à installer (beaucoup d'outils graphiques)
- Debian cherche à faire quelque chose de très stable et de très cohérent, quitte à attendre pour intégrer quelque chose.
- Gentoo cherche à faire un système optimisé via une recompilation "sur mesure"
Et ainsi de suite, chaque distribs a sa philosophie. A partir des mêmes ingrédients, chacun fait sa recette, selon les goûts. Mais selon moi, les développeurs des distribs n'ont pas à modifier les programmes en eux même, si ce n'est suggérer des amélioration ou soumettre des bugs, vu qu'ils en ont les compétences. C'est peut être d'ailleurs la seule chose qu'il font.
Tu sais, tu as tout un tas de voitures différentes, et pourtant, ça choque personne.
Une Xsara et une 306 sont faites à partir des mêmes pièces (chassis, moteurs, mécanique ...), mais des choix dans la sélection des pièces et les réglages, plus des éléments spécifiques en font des voitures totalement différentes. Pareil pour la VW Golf et des dérivés Audi A3/Seat/Skoda. Il y a des alliances entre constructeurs pour partager le développement de chassis et de moteurs. Pour l'automobile, ce n'est que dans une logique d'économie industrielle. Mais au final, le travail de développement des pièces communes est partagé, mais permet quand même à chacun de faire des produits très différents.
Mais d'une part, quand je parlais de Linux, j'englobais tout les softs qui tournent dessus (erreur courante). J'ai par exemple eu ce problème pour mettre à jour Mozilla sur une Mandrake 9.0 (avec un rpm pris sur un CD Mandrake 9.1).
D'autre part, le problème se rencontre pour une simple installation d'un paquet récent. Je me rappel avoir du passer d'une Mandrake 7.x à 8.0 pour pouvoir installer un soft (peut être gnomeICU), car quelque soit le Rpm que j'essayais, il lui fallait mettre à jour une tonne d'autre Rpm. Plus récement, je ne pouvais pas installer les RPM mozilla ou OpenOffice sur ma Mandrake 8.0. Pendant ce temps, j'essayais les dits programmes sur le même micro ... sous Windows 98, sans aller chercher autre chose que le .exe d'installation.
Malheureusement, ces deux distributions avaient l'habitude de patcher à leur sauce des éléments centraux du systemes comme le noyau, la libc ou gcc. ET c'est bien là d'ou viens le problème : rendant beaucoup de soft imcompilables ou instables pour divers effets de bord.
On en est où avec ces problèmes d'incompatibilité ? Je sais qu'à une époque, c'est le fameux gcc 2.96 qui a posé problème, mais maintenant on est passé à gcc 3.xx. Tout à l'heure, en cherchant comment faire des Rpms, je suis tombé sur " The package rpm which is our patched version of Red Hat's." dans le HowTo des Rpms pour Mandrake (http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowTo(...))
Et autre question que j'ai déjà posé ailleurs (et pour laquelle je n'ai pas encore eu de réponse satisfaisante), a quoi ça leur sert de modifier les sources ainsi ? Tant qu'il s'agit d'appliquer de bon patch, pourquoi pas, mais quand ça casse la compatibilité, ça ne fait que jouer le jeu du "concurent", car au lieu d'avoir GNU/Linux, on d'un coté Debian, de l'autre Mandrake ... Bref, de l'énergie dispersée pour rien !
On pourrait faire une analogie avec l'édition de livres. On retrouve beucoup de livres (programmes) dans beaucoup de collections (distributions) différentes. Plus ou moins complète, plus ou moins jolie, avec des illustrations pour l'un ... Mais dans le monde de l'édition, le texte reste le même, que l'on lise le roman édité par "J'ai lu" ou par "Le livre de poche". On ferait comment pour lire tous les épisodes d'une même histoire si les noms des personnages changeait d'un éditeur à l'autre ?
Pas de API souple et uniforme pour pouvoir interfacer des modules drivers des constructeurs
Il n'y a pas que cela. Les changement continus d'ABI entre les différentes versions de gcc donne que si tu crée une application sur une distribution, elle a toutes les chances de ne pas marcher sur une autre.
C'est quoi ces histoires de changement d'ABI avec gcc ? Il me semble avoir déjà lu des remarques la dessus, mais mes connaissance en programmation étant assez liumitée ( #include xxx, make et c'est presque tout), j'ai pas encore vraiment compris comment ça marche.
Comme d'autres, je trouve qu'il y a du vrai et du faux la-dedans :
- Mauvais support des imprimantes :
C'est plutôt un mauvais support de l'OS par les constructeurs. J'ai toujours trouvé idiot les sigles "Designed fox Windows XXX", mais ça reste quand même aux fabriquants de fournir les drivers, du moins tant qu'on aurat pas défini une norme de dialogue pour les imprimantes (mais est-ce faisable ?).
Mon Windows XP tout beau tout neuf ne savais pas quoi faire de mon ancienne imprimante Canon, tant que je ne lui avais pas fourni les drivers de Canon.
- Mauvais support des périphériques USB : Pas mal de périphériques USB fonctionnent encore mal sous Linux : mon pote sous SuSE 8.0 a parfois des difficultés à faire fonctionner son appareil photo numérique : parfois ça marche, parfois ça marche pas. Sous Mandrake 9.1, meme difficultés.
Pour élargir au support de périphériques en général, mon expérience me donne un ex-aequo entre Windows XP et Mandrake 9.1 sur mon matériel :
- modem intégré : ne marche que sous Windows, et que depuis que j'ai téléchargé le driver sur internet
- Scanner Mustek sur port parallèle : marche tout seul sous Linux (si ce n'est un soucis d'accès au port parallèle pour un utilisateur non root). Windows ne le voit pas, il ne propose aucun périphérique Mustek dans Ajout/Suppression de périphérique, et même avec les drivers trouvés sur le site Mustek, ça ne donne rien.
- graveur Iomega USB : sur des roulettes sur les 2 OS (mais pas utilisé sous Windows).
- Lecteur ZIP parallèle : marche sur les 2 OS, mais 3 fois plus rapide sur Linux (même disquette/fichiers), et je n'ai pas besoin qu'il soit allumer lors du boot du PC.
- bouton "multimedia" du clavier : ne marche que sous Windows et que depuis que j'ai téléchargé les drivers.
- vieille carte réseau PCMCIA : marche toute seule sous Linux, périphérique inconne pour Windows.
Bref, y'en a pas un qui s'en sort mieux que l'autre à ce niveau. Et encore, pour Windows, c'est parce que le fabriquant du PC (Nec) fournit les drivers sur son site. Sans accès internet, ce serait pire pour WinXP.
- Configuration de son système : Difficulté pour ajouter un périphérique recalcitrant, alors que sous Windows en général ça passe tout seul.
Pour compléter ce que j'ai mis juste avant : Si ça marche tout seul sous Windows, ça va, sinon, rien à faire. Sous Linux, y'a toujours moyen de débuger/chercher.
- Les outils de gravage restent moins conviviaux que les equivalents Windows (applis préférées : GnomeToaster, KonCD/Kreate CD)
Je n'ai quasiment jamais gravé sous Windows (et c'était vite fait au boulot). Par contre, sous Linux, j'utilise Xcdroast, et ça me semble sufisament conviviale.
- Pas de API souple et uniforme pour pouvoir interfacer des modules drivers des constructeurs (si bien que si je veux installer un module du 2.4.19 sur un 2.4.23, et que c'est un binaire, je suis baisé)
La, je suis d'accord. Mais les raisons de ce problème ont été données plus haut.
Y'a un autre défaut que j'ai déjà signalé dans d'autres sujets, mais au niveau des distributions et de la diffusion sous forme binaire. C'est la gestion des dépendances. Pour mettre à jour un RPM (sur Mandrake du moins), y'a souvent besoin de mettre à jour beaucoup de paquets, ce qui peut faire beaucoup à télécharger, surtout avec un modem 56K. Je ne sais si c'est obligé (pour cause d'utilisation de nouvelle fonction de telle bibliothèque) ou s'il est difficile de gérer ça convenablement, mais je trouve que ça rend les mise à jour parfois plus complexe que sous Windows.
Evidement, le problème ne se pose par lorsqu'on compile à partir des sources, mais on perd alors tout l'avantage des systèmes de Rpm (ou autre).
Regarde toujour le fichier /etc/ssh/ssh_config (chemin variable d'une distrib à l'autre) si tu as une ligne du genre :
ForwardX11 yes (ou ForwardX11 no, forcément)
Si c'est à no, cherches pas plus loin. S'il est à yes, le problème est ailleur. S'il n'y a rien de ce genre, je n'ai aucune idée du comportement par défaut.
Tiens, presque que le même sujet que le journal que j'ai posté juste avant :o)
T'as regardé la configuration coté serveur ? Il peut refuser le X11-forwarding. Et ça doit pouvoir se configurer au niveau du système (/etc/...) ou du répertoire utilisateur.
Au niveau des PCs de bureau, on peut en effet se fier plus ou moins au satistiques des sites internet.
Mais pour les serveurs, on n'a de chiffres que pour les "ventes" et les serveurs directement connecté à internet (et hébergeant des services). J'ai bossé 6 mois avec un indépendant en informatique. Quand il installe des serveurs dans des PME, c'est généralement du Linux. Il commence aussi à installer des boitiers pré-installés pour faire du VPN entre les quelques sites physique de certains clients. Ces boitiers contiennent aussi du Linux.
Certes, ça ne fait pas des milliers de machines, mais il n'y a aucun moyen de comptabiliser des serveurs qui tournent sur des réseaux privés, ou qui n'héberge aucun service accessible sur internet (comme les serveurs web).
- Pendant la période de validité du brevet, je ne peux ni copier, ni m'inspirer de l'original.
- Après la période de validité, je ne peux toujours pas copier, mais je peux par contre m'en inspirer ?
(On dérive un peu, mais c'est toujous bon de bien comprendre tout ces problèmes de brevet/propriété intelectuelle)
Pour finir un brevet dure 20 ans, mais la propriete intellectuelle sur le code c'est beaucoup plus long, au nom du droit d'auteur une copie verbatim du code est protege pendant 50 a 70 ans suivant les pays. C'est valable aussi pour la GPL qui s'appuie tres fort sur cette protection par droit d'auteur.
Et au nom de la propriété intellectuelle, qu'est ce qu'une boîte comme SCO peut faire ou peut empécher de faire, à part se faire reconnaitre comme auteur original ? Le brevet proprement dit n'étant plus valable, ils ne peuvent empécher l'utilisation libre du bout de code en question.
- Unix première version date de 1969
- Unix et BSD ont beaucoup été développés au début des années 1980
- Qu'un brevet dure 20 ans
- Que certaines technologies d'Unix ont été mise dès le départ dans le domaine public (corrigé moi si je me trompe)
Qu'est ce qu'il reste de protégé par des droits, à par le nom et des trucs très récents développé par IBM/HP/Sun/Linux chacun de son bord ?
J'ai récemment installé une Mandrake 9.0 sur un micro. Comme il était destiné à offrir un accès internet, j'ai voulu mettre à jour Mozilla, avec le RPM présent sur un CD Mandrake 9.1 que j'avais acheté entre temps (un mozilla 1.3). Dans ce cas précis, il y avait énormément de packages à mettre à jour, et j'ai du laissé tombé.
Plus récement, j'ai téléchargé les binaires de mozilla 1.4 sur le site mozilla.org, pour les installés sur mon propre micro, tournant sur une Mandrake 8.0. Et bien tout à parfaitement marché, sans problème de bibliothèque trop ancienne.
Cette exemple me laisse pensé que quelques chose est mal géré quelque part. Soit c'est Mandrake qui compile des RPM avec des bibliothèques très récentes, soit c'est le système de dépendances qui est trop exigeant/contraignant.
Je veux bien croire que gérer ça au mieux implique plus de travail. Mais je crois que ça offrirait plus de souplesse pour les mises à jour. C'est le seul défaut que je trouve actullement à cette distrib.
Ca m'étonne d'autant plus que je n'ai pas de soucis pour installer des softs récents sous mon vieux Windows 98 ...
Je parlais de mises à jour de sécurité. Je me doutes bien qu'on ne peut assurer longtemps le suivi d'autant de programmes.
Mais il faut dire aussi, que même en se limitant à la sécurité, cela touche aussi les navigateurs web, les clients de messagerie instantanées ... beaucoup de choses quand même.
Y'a une question que ne me pose sur la Mandrake. Quelle est la nature des modifications qu'ils apportent aux programmes fournis ? Visiblement, tout leur packages comportent des modifications par rapport aux sources de départ, créant parfois des incompatibilité avec des binaires non-Mandrake, ou de drôles de dépendances.
Je sais que pour le noyau, ce sont simplement des patchs, parfois utiles. Mais je sais qu'à une époque, ils ont utilisé le gcc 2.96, avec tous les problèmes que l'ont sais (plus ou moins, j'ai suivi cette histoire de loin).
Si je pose cette question, c'est que pour moi, le rôle d'une bonne distrib, c'est :
- faire un regroupement cohérent de softs et de bibliothèques (ce qui est loin d'être évident avec toutes les dépendances)
- faire le travail de compilation (qui n'est pas à la portée de tout le monde)
- fournir un bon programme d'installation du système
Ce que fait très bien Mandrake. Accesoirement, ils peuvent créer leur propre programmes (comme rpmdrake que j'apprécie énormément). Mais pourquoi modifier les programmes et bibliothèques fournis ? Le système des RPMs permet de très facilement installer/supprimer des programmes, mais dès qu'on commence à compiler ses propres sources, ou à installer des binaires de différentes sources, on peut craindre les soucis.
Ou alors, dès que l'on veut mettre à jour 1 programmes via RPM, il y a une liste de dépendances à mettre à jour impressionnante, alors que le dit programme marche très bien s'il est compilé avec le système de départ !
De toute façon, ce qu'on appelle une "desktop" update correspond in fine à une update à la version de Mandrake suivante. Tant que la distribution est fournie gratuitement, ce qui est le cas dans leur charte, il n'y aura jamais aucun problème à faire l'update et à se retrouver dans les limites de temps de la version suivante. Et le support peut être contracté de façon séparée par email ou par téléphone.
Effectivement, un utilisateur de Mandrake 8.0 peut se mettre à jour vers un Mandrake 9.2 gratuitement. Malheureusement, la mise à jour d'un système se traduit souvent vers la mise à jour de plusieurs programmes, avec plus de fonctionnalités. Et donc plus lourd !
Donc, un micro marchant parfaitement avec une 8.0 deviendrat lent avec une version récente (j'en ai fait l'expérience). Une grosse mise à jour impliquerait donc une mise à jour du matériel. Et on se retrouve dans la même situation qu'avec un autre OS ...
L'idéal serait donc de continuer plus longtemps (mais pas éternellement non plus) à faire les mise à jour de sécurité de quelques versions, afin d'assurer la sécurité de PC anciens, incapables de faire tourner correctement une distrib récente. Je ne sais pas quel est la logique dans les numéros de versions Mandrake, mais en supposant (par exemple) que les 8.0, 8.1 et 8.2 sont des évolutions mineures par rapport au passage en 9.0, on peut imaginer un support plus long sur les 8.2, qui resterait une versions à jour en terme de sécurité disponible pour de vieux micro.
Sur le même principe, on peut se limiter à certaines branche, la 6.x, puis la 8.x, afin de ne pas multiplier le travail de suivi.
Si je lis bien, c'est un accord qui permet aux établissement scolaires d'avoir de bons prix. Mais ça n'engage pas plus que ça l'Education Nationale (heureusement).
Et comme tout le monde le sais, le prix d'un système/logiciel n'est pas le seul argument en faveur du libre.
Lien intéressant. Mais j'ai un portable, et dans ce cas, il n'est pas évident de tout démonter pour aller lire ce qu'il y a écrit sur le processeur. Mais ça aidera toujours ceux qui ont un PC de bureau.
Pour le /proc/cpuinfo, j'ai :
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 11
model name : Intel(R) Celeron(TM) CPU 1300MHz
stepping : 4
cpu MHz : 1302.959
cache size : 256 KB
[...]
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 2601.77
Il serait donc basé sur un Pentium III d'après les indications un peu plus bas.
mais normallement tu dois pouvoir aussi l identifier avec le /proc/cpuinfo , en particulier les champs "cpu family" "model " et "stepping" le probleme
c est qu il faut savoir a quoi les associer :)
Ca serait bien qu'ils l'indiquent dans l'aide de la configuration du noyau. Je n'ai rien trouvé à ce sujet sur le net.
J'ai une petite question, qui en intéressera sans doutes d'autres. Dans le choix du proceseur, Le Celeron apparait avec 3 générations de Pentium (II, III et 4). Comment puis-je savoir à quelle génération correspond mon Celeron ? Avec des infos dans /proc/cpuinfo ? J'ai rien trouvé dans les docs ni sur le net.
Je sais que je peux choisir la génération la plus ancienne pour être sur, mais tant qu'à faire, autant prendre la bonne et profiter à fond de ses capacités.
(Intel me fait penser aux constructeurs de voitures qui collent le même nom à plusieurs générations de voiture qui n'ont rien de commun : Golf, Clio ...)
Posté par Jllc .
En réponse au journal google....
Évalué à 3.
Et il a fait quoi avec son Eole ? Une tondeuse à gazon ?
Les frères Wright ont amélioré à leur tour cette invention (en faisant un engin vraiment pilotable), comme de nombreux ingénieurs et pilotes (bien avant Clément Ader pour certains). Mais ce n'est pas parce que les américains ont une certaines amnésie sur ce qui se fait ailleurs qu'on doit les suivre dans cette célébration du "centenaire de l'aviation".
C'est le centenaire d'un étape importante, mais pas le centenaire de toute l'aviation tout court.
Y'a une question que je me pose (surtout après les explications un peu plus haut sur le fonctionnement des toolkits/thèmes). Au niveau de l'application, y'a t-il de grosses différences selon le toolkit GTK/Qt/Win32 ..., rendant difficile le port sur un autre OS ?
A ma connaissance, on retrouve toujours les mêmes widgets (boutons, menu, listes, conteneurs ...) fonctionnant toujours sur le même principe. Pour organiser l'interface, on imbrique les conteneurs, les mêmes widgets ont toujours les mêmes propriétés (label dans un bouton ..). Après, selon le toolkit utilisé, c'est plus ou moins rapide, plus ou moins gourmand en mémoire, plus ou moins joli ...
La réponse semble oui puisque chaque projet multi-plateforme (Mozilla, OpenOffice) refait sa propre moulinette, mais je ne comprends pas pouquoi.
2) une consommation électrique énorme, en gros, tu tiens 2 heures en continu sur piles/batteries. Le cout n'est donc pas a négliger (achat d'autres batteries/piles; privilegeir les APN qui fonctionnent avec les 2, ça peut toujours servir, à l'étranger par ex.)
Point très important la consommation électrique. Pendant les premières semaines, les économies en pellicules/développement sont parties dans les piles. Il faut donc prévoir des piles rechargeables et un bon chargeur. Conseil : avoir 2 jeux de piles (l'un charge pendant que l'autre sert) pour ceux qui photographient beaucoup.
Toujours pour les piles, je peux dire après 2 ans d'expérience que les piles rechargeables ne tiennent pas les milles recharges promises. J'ai un jeu de piles moisies (oxydées) et l'autre tient très mal la charge. Il faut donc bien choisir ses piles et le chargeur. D'après ce que j'ai lu, il y a des chargeurs "intelligent" qui déchargent proprement les piles avant une nouvelle charge (pour éviter l'effet mémoire) et qui contrôlent séparemment la charge des piles branchées dessus, afin de faire ça au mieux. Par contre, je n'ai pas de marque/modèle à conseiller.
# Re: Remplacement d'un écran de portable
Posté par Jllc . En réponse au journal Remplacement d'un écran de portable. Évalué à 4.
Aucune idée du prix actuel, mais à une époque, je les avais vu sur le site Toshiba : presque le prix d'un portable neuf !
Mais heureusement, ça peut toujours se recycler soit un PC ordinaire en branchant écran+clavier+souris externes, soit en serveur de ce qu'on veut en réseau (plus besoin d'écran).
[^] # Re: Problème réseau entre 2 PC avec SSH + X11forwarding
Posté par Jllc . En réponse au journal Problème réseau entre 2 PC avec SSH + X11forwarding. Évalué à 1.
Ce matin, j'ai encore eu le problème, mais ethereal a bien voulu marché. En fait, c'est au niveau ARP que ça coince. Le PC neuf demande en broadcast quelle est l'adresse ethernet correspondant à l'IP du vieux micro. L'ethereal du vieux voit partir la réponse, mais sur le neuf, on ne voit pas cette réponse. Bizarre ... Je vais donc voir comment débuger ça.
Pour l'ethereal qui gèle en local, ce n'est peut être qu'une coïncidence, mais je l'ai mentionné au cas où, car je ne l'ai vu geler que dans cette circonstance.
[^] # Re: C'est malheureux à dire mais Mandrake n'est pas prêt pour le desktop
Posté par Jllc . En réponse au journal Linux pas prêt pour le desktop. Évalué à 1.
Si toutes les distros étaient exactement pareils, ça servirais a quoi d'en avoir plusieurs ?
Comme je l'ai déjà dis ailleurs, les développeurs développent chacun de leur coté, en ne fournissant que les sources, et de manière complètement asynchrone par rapport aux soft/bibliothèques qu'ils utilisent. Je serais donc comme beaucoup incapables d'aller chercher de tous les cotés tout les sources de tout ce qui est sur mon micro (des briques de bases jusqu'aux grosses applis) et de réussir à faire marcher le tout ensemble.
C'est là que les distribs ont leur place : faire une sélection cohérente de sources (par rapport aux dépendances), faire le travail de compilation, et fournir un outil d'installation/gestion des paquets.
Pourquoi plusieurs distribs ? Parce qu'on peut gérer ça de différentes manières :
- Mandrake cherche à avoir des trucs récents (instables selon certains), et très facile à installer (beaucoup d'outils graphiques)
- Debian cherche à faire quelque chose de très stable et de très cohérent, quitte à attendre pour intégrer quelque chose.
- Gentoo cherche à faire un système optimisé via une recompilation "sur mesure"
Et ainsi de suite, chaque distribs a sa philosophie. A partir des mêmes ingrédients, chacun fait sa recette, selon les goûts. Mais selon moi, les développeurs des distribs n'ont pas à modifier les programmes en eux même, si ce n'est suggérer des amélioration ou soumettre des bugs, vu qu'ils en ont les compétences. C'est peut être d'ailleurs la seule chose qu'il font.
Tu sais, tu as tout un tas de voitures différentes, et pourtant, ça choque personne.
Une Xsara et une 306 sont faites à partir des mêmes pièces (chassis, moteurs, mécanique ...), mais des choix dans la sélection des pièces et les réglages, plus des éléments spécifiques en font des voitures totalement différentes. Pareil pour la VW Golf et des dérivés Audi A3/Seat/Skoda. Il y a des alliances entre constructeurs pour partager le développement de chassis et de moteurs. Pour l'automobile, ce n'est que dans une logique d'économie industrielle. Mais au final, le travail de développement des pièces communes est partagé, mais permet quand même à chacun de faire des produits très différents.
[^] # Re: Qu'est ce qu'il manque à Linux pour pouvoir s'introduire au coté de Mac OS et Windows chez le particulier ?
Posté par Jllc . En réponse au journal Qu'est ce qu'il manque à Linux pour pouvoir s'introduire au coté de Mac OS et Windows chez le particulier ?. Évalué à 1.
Mais d'une part, quand je parlais de Linux, j'englobais tout les softs qui tournent dessus (erreur courante). J'ai par exemple eu ce problème pour mettre à jour Mozilla sur une Mandrake 9.0 (avec un rpm pris sur un CD Mandrake 9.1).
D'autre part, le problème se rencontre pour une simple installation d'un paquet récent. Je me rappel avoir du passer d'une Mandrake 7.x à 8.0 pour pouvoir installer un soft (peut être gnomeICU), car quelque soit le Rpm que j'essayais, il lui fallait mettre à jour une tonne d'autre Rpm. Plus récement, je ne pouvais pas installer les RPM mozilla ou OpenOffice sur ma Mandrake 8.0. Pendant ce temps, j'essayais les dits programmes sur le même micro ... sous Windows 98, sans aller chercher autre chose que le .exe d'installation.
[^] # Re: C'est malheureux à dire mais Mandrake n'est pas prêt pour le desktop
Posté par Jllc . En réponse au journal Linux pas prêt pour le desktop. Évalué à 2.
On en est où avec ces problèmes d'incompatibilité ? Je sais qu'à une époque, c'est le fameux gcc 2.96 qui a posé problème, mais maintenant on est passé à gcc 3.xx. Tout à l'heure, en cherchant comment faire des Rpms, je suis tombé sur " The package rpm which is our patched version of Red Hat's." dans le HowTo des Rpms pour Mandrake (http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowTo(...))
Et autre question que j'ai déjà posé ailleurs (et pour laquelle je n'ai pas encore eu de réponse satisfaisante), a quoi ça leur sert de modifier les sources ainsi ? Tant qu'il s'agit d'appliquer de bon patch, pourquoi pas, mais quand ça casse la compatibilité, ça ne fait que jouer le jeu du "concurent", car au lieu d'avoir GNU/Linux, on d'un coté Debian, de l'autre Mandrake ... Bref, de l'énergie dispersée pour rien !
On pourrait faire une analogie avec l'édition de livres. On retrouve beucoup de livres (programmes) dans beaucoup de collections (distributions) différentes. Plus ou moins complète, plus ou moins jolie, avec des illustrations pour l'un ... Mais dans le monde de l'édition, le texte reste le même, que l'on lise le roman édité par "J'ai lu" ou par "Le livre de poche". On ferait comment pour lire tous les épisodes d'une même histoire si les noms des personnages changeait d'un éditeur à l'autre ?
[^] # Re: Qu'est ce qu'il manque à Linux pour pouvoir s'introduire au coté de Mac OS et Windows chez le particulier ?
Posté par Jllc . En réponse au journal Qu'est ce qu'il manque à Linux pour pouvoir s'introduire au coté de Mac OS et Windows chez le particulier ?. Évalué à 1.
Il n'y a pas que cela. Les changement continus d'ABI entre les différentes versions de gcc donne que si tu crée une application sur une distribution, elle a toutes les chances de ne pas marcher sur une autre.
C'est quoi ces histoires de changement d'ABI avec gcc ? Il me semble avoir déjà lu des remarques la dessus, mais mes connaissance en programmation étant assez liumitée ( #include xxx, make et c'est presque tout), j'ai pas encore vraiment compris comment ça marche.
# Re: Qu'est ce qu'il manque à Linux pour pouvoir s'introduire au coté de Mac OS et Windows chez le particulier ?
Posté par Jllc . En réponse au journal Qu'est ce qu'il manque à Linux pour pouvoir s'introduire au coté de Mac OS et Windows chez le particulier ?. Évalué à 1.
- Mauvais support des imprimantes :
C'est plutôt un mauvais support de l'OS par les constructeurs. J'ai toujours trouvé idiot les sigles "Designed fox Windows XXX", mais ça reste quand même aux fabriquants de fournir les drivers, du moins tant qu'on aurat pas défini une norme de dialogue pour les imprimantes (mais est-ce faisable ?).
Mon Windows XP tout beau tout neuf ne savais pas quoi faire de mon ancienne imprimante Canon, tant que je ne lui avais pas fourni les drivers de Canon.
- Mauvais support des périphériques USB : Pas mal de périphériques USB fonctionnent encore mal sous Linux : mon pote sous SuSE 8.0 a parfois des difficultés à faire fonctionner son appareil photo numérique : parfois ça marche, parfois ça marche pas. Sous Mandrake 9.1, meme difficultés.
Pour élargir au support de périphériques en général, mon expérience me donne un ex-aequo entre Windows XP et Mandrake 9.1 sur mon matériel :
- modem intégré : ne marche que sous Windows, et que depuis que j'ai téléchargé le driver sur internet
- Scanner Mustek sur port parallèle : marche tout seul sous Linux (si ce n'est un soucis d'accès au port parallèle pour un utilisateur non root). Windows ne le voit pas, il ne propose aucun périphérique Mustek dans Ajout/Suppression de périphérique, et même avec les drivers trouvés sur le site Mustek, ça ne donne rien.
- graveur Iomega USB : sur des roulettes sur les 2 OS (mais pas utilisé sous Windows).
- Lecteur ZIP parallèle : marche sur les 2 OS, mais 3 fois plus rapide sur Linux (même disquette/fichiers), et je n'ai pas besoin qu'il soit allumer lors du boot du PC.
- bouton "multimedia" du clavier : ne marche que sous Windows et que depuis que j'ai téléchargé les drivers.
- vieille carte réseau PCMCIA : marche toute seule sous Linux, périphérique inconne pour Windows.
Bref, y'en a pas un qui s'en sort mieux que l'autre à ce niveau. Et encore, pour Windows, c'est parce que le fabriquant du PC (Nec) fournit les drivers sur son site. Sans accès internet, ce serait pire pour WinXP.
- Configuration de son système : Difficulté pour ajouter un périphérique recalcitrant, alors que sous Windows en général ça passe tout seul.
Pour compléter ce que j'ai mis juste avant : Si ça marche tout seul sous Windows, ça va, sinon, rien à faire. Sous Linux, y'a toujours moyen de débuger/chercher.
- Les outils de gravage restent moins conviviaux que les equivalents Windows (applis préférées : GnomeToaster, KonCD/Kreate CD)
Je n'ai quasiment jamais gravé sous Windows (et c'était vite fait au boulot). Par contre, sous Linux, j'utilise Xcdroast, et ça me semble sufisament conviviale.
- Pas de API souple et uniforme pour pouvoir interfacer des modules drivers des constructeurs (si bien que si je veux installer un module du 2.4.19 sur un 2.4.23, et que c'est un binaire, je suis baisé)
La, je suis d'accord. Mais les raisons de ce problème ont été données plus haut.
Y'a un autre défaut que j'ai déjà signalé dans d'autres sujets, mais au niveau des distributions et de la diffusion sous forme binaire. C'est la gestion des dépendances. Pour mettre à jour un RPM (sur Mandrake du moins), y'a souvent besoin de mettre à jour beaucoup de paquets, ce qui peut faire beaucoup à télécharger, surtout avec un modem 56K. Je ne sais si c'est obligé (pour cause d'utilisation de nouvelle fonction de telle bibliothèque) ou s'il est difficile de gérer ça convenablement, mais je trouve que ça rend les mise à jour parfois plus complexe que sous Windows.
Evidement, le problème ne se pose par lorsqu'on compile à partir des sources, mais on perd alors tout l'avantage des systèmes de Rpm (ou autre).
[^] # Re: Pourquoi le ssh -X ne marche pas ?
Posté par Jllc . En réponse au journal Pourquoi le ssh -X ne marche pas ?. Évalué à 2.
Regarde toujour le fichier /etc/ssh/ssh_config (chemin variable d'une distrib à l'autre) si tu as une ligne du genre :
ForwardX11 yes (ou ForwardX11 no, forcément)
Si c'est à no, cherches pas plus loin. S'il est à yes, le problème est ailleur. S'il n'y a rien de ce genre, je n'ai aucune idée du comportement par défaut.
# Re: Pourquoi le ssh -X ne marche pas ?
Posté par Jllc . En réponse au journal Pourquoi le ssh -X ne marche pas ?. Évalué à 3.
T'as regardé la configuration coté serveur ? Il peut refuser le X11-forwarding. Et ça doit pouvoir se configurer au niveau du système (/etc/...) ou du répertoire utilisateur.
[^] # Re: Evolution de Mozilla et autres stats...
Posté par Jllc . En réponse au journal Evolution de Mozilla et autres stats.... Évalué à 2.
Mais pour les serveurs, on n'a de chiffres que pour les "ventes" et les serveurs directement connecté à internet (et hébergeant des services). J'ai bossé 6 mois avec un indépendant en informatique. Quand il installe des serveurs dans des PME, c'est généralement du Linux. Il commence aussi à installer des boitiers pré-installés pour faire du VPN entre les quelques sites physique de certains clients. Ces boitiers contiennent aussi du Linux.
Certes, ça ne fait pas des milliers de machines, mais il n'y a aucun moyen de comptabiliser des serveurs qui tournent sur des réseaux privés, ou qui n'héberge aucun service accessible sur internet (comme les serveurs web).
[^] # Re: Spéculons
Posté par Jllc . En réponse au journal Les réclamations de SCO. Évalué à 1.
- Pendant la période de validité du brevet, je ne peux ni copier, ni m'inspirer de l'original.
- Après la période de validité, je ne peux toujours pas copier, mais je peux par contre m'en inspirer ?
(On dérive un peu, mais c'est toujous bon de bien comprendre tout ces problèmes de brevet/propriété intelectuelle)
[^] # Re: Spéculons
Posté par Jllc . En réponse au journal Les réclamations de SCO. Évalué à 1.
[^] # Re: Spéculons
Posté par Jllc . En réponse au journal Les réclamations de SCO. Évalué à 1.
Et au nom de la propriété intellectuelle, qu'est ce qu'une boîte comme SCO peut faire ou peut empécher de faire, à part se faire reconnaitre comme auteur original ? Le brevet proprement dit n'étant plus valable, ils ne peuvent empécher l'utilisation libre du bout de code en question.
[^] # Re: Spéculons
Posté par Jllc . En réponse au journal Les réclamations de SCO. Évalué à 1.
- Unix première version date de 1969
- Unix et BSD ont beaucoup été développés au début des années 1980
- Qu'un brevet dure 20 ans
- Que certaines technologies d'Unix ont été mise dès le départ dans le domaine public (corrigé moi si je me trompe)
Qu'est ce qu'il reste de protégé par des droits, à par le nom et des trucs très récents développé par IBM/HP/Sun/Linux chacun de son bord ?
[^] # Re: "8 Règles d'Or" pour les produits Mandrake Linux
Posté par Jllc . En réponse à la dépêche "8 Règles d'Or" pour les produits Mandrake Linux. Évalué à -1.
Plus récement, j'ai téléchargé les binaires de mozilla 1.4 sur le site mozilla.org, pour les installés sur mon propre micro, tournant sur une Mandrake 8.0. Et bien tout à parfaitement marché, sans problème de bibliothèque trop ancienne.
Cette exemple me laisse pensé que quelques chose est mal géré quelque part. Soit c'est Mandrake qui compile des RPM avec des bibliothèques très récentes, soit c'est le système de dépendances qui est trop exigeant/contraignant.
Je veux bien croire que gérer ça au mieux implique plus de travail. Mais je crois que ça offrirait plus de souplesse pour les mises à jour. C'est le seul défaut que je trouve actullement à cette distrib.
Ca m'étonne d'autant plus que je n'ai pas de soucis pour installer des softs récents sous mon vieux Windows 98 ...
[^] # Re: Durée de support
Posté par Jllc . En réponse à la dépêche "8 Règles d'Or" pour les produits Mandrake Linux. Évalué à 2.
Mais il faut dire aussi, que même en se limitant à la sécurité, cela touche aussi les navigateurs web, les clients de messagerie instantanées ... beaucoup de choses quand même.
# Re: "8 Règles d'Or" pour les produits Mandrake Linux
Posté par Jllc . En réponse à la dépêche "8 Règles d'Or" pour les produits Mandrake Linux. Évalué à 4.
Je sais que pour le noyau, ce sont simplement des patchs, parfois utiles. Mais je sais qu'à une époque, ils ont utilisé le gcc 2.96, avec tous les problèmes que l'ont sais (plus ou moins, j'ai suivi cette histoire de loin).
Si je pose cette question, c'est que pour moi, le rôle d'une bonne distrib, c'est :
- faire un regroupement cohérent de softs et de bibliothèques (ce qui est loin d'être évident avec toutes les dépendances)
- faire le travail de compilation (qui n'est pas à la portée de tout le monde)
- fournir un bon programme d'installation du système
Ce que fait très bien Mandrake. Accesoirement, ils peuvent créer leur propre programmes (comme rpmdrake que j'apprécie énormément). Mais pourquoi modifier les programmes et bibliothèques fournis ? Le système des RPMs permet de très facilement installer/supprimer des programmes, mais dès qu'on commence à compiler ses propres sources, ou à installer des binaires de différentes sources, on peut craindre les soucis.
Ou alors, dès que l'on veut mettre à jour 1 programmes via RPM, il y a une liste de dépendances à mettre à jour impressionnante, alors que le dit programme marche très bien s'il est compilé avec le système de départ !
[^] # Re: Durée de support
Posté par Jllc . En réponse à la dépêche "8 Règles d'Or" pour les produits Mandrake Linux. Évalué à 4.
Effectivement, un utilisateur de Mandrake 8.0 peut se mettre à jour vers un Mandrake 9.2 gratuitement. Malheureusement, la mise à jour d'un système se traduit souvent vers la mise à jour de plusieurs programmes, avec plus de fonctionnalités. Et donc plus lourd !
Donc, un micro marchant parfaitement avec une 8.0 deviendrat lent avec une version récente (j'en ai fait l'expérience). Une grosse mise à jour impliquerait donc une mise à jour du matériel. Et on se retrouve dans la même situation qu'avec un autre OS ...
L'idéal serait donc de continuer plus longtemps (mais pas éternellement non plus) à faire les mise à jour de sécurité de quelques versions, afin d'assurer la sécurité de PC anciens, incapables de faire tourner correctement une distrib récente. Je ne sais pas quel est la logique dans les numéros de versions Mandrake, mais en supposant (par exemple) que les 8.0, 8.1 et 8.2 sont des évolutions mineures par rapport au passage en 9.0, on peut imaginer un support plus long sur les 8.2, qui resterait une versions à jour en terme de sécurité disponible pour de vieux micro.
Sur le même principe, on peut se limiter à certaines branche, la 6.x, puis la 8.x, afin de ne pas multiplier le travail de suivi.
# Re: L'Education nationale signe un accord-cadre avec Microsoft
Posté par Jllc . En réponse au journal L'Education nationale signe un accord-cadre avec Microsoft. Évalué à 3.
Et comme tout le monde le sais, le prix d'un système/logiciel n'est pas le seul argument en faveur du libre.
[^] # Re: Choix d'un processeur Celeron
Posté par Jllc . En réponse à la dépêche Le noyau Linux 2.6.0 annoncé stable. Évalué à 1.
Pour le /proc/cpuinfo, j'ai :
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 11
model name : Intel(R) Celeron(TM) CPU 1300MHz
stepping : 4
cpu MHz : 1302.959
cache size : 256 KB
[...]
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 2601.77
Il serait donc basé sur un Pentium III d'après les indications un peu plus bas.
mais normallement tu dois pouvoir aussi l identifier avec le /proc/cpuinfo , en particulier les champs "cpu family" "model " et "stepping" le probleme
c est qu il faut savoir a quoi les associer :)
Ca serait bien qu'ils l'indiquent dans l'aide de la configuration du noyau. Je n'ai rien trouvé à ce sujet sur le net.
# Choix d'un processeur Celeron
Posté par Jllc . En réponse à la dépêche Le noyau Linux 2.6.0 annoncé stable. Évalué à 2.
Je sais que je peux choisir la génération la plus ancienne pour être sur, mais tant qu'à faire, autant prendre la bonne et profiter à fond de ses capacités.
(Intel me fait penser aux constructeurs de voitures qui collent le même nom à plusieurs générations de voiture qui n'ont rien de commun : Golf, Clio ...)
[^] # Re: google...
Posté par Jllc . En réponse au journal google.... Évalué à 3.
Les frères Wright ont amélioré à leur tour cette invention (en faisant un engin vraiment pilotable), comme de nombreux ingénieurs et pilotes (bien avant Clément Ader pour certains). Mais ce n'est pas parce que les américains ont une certaines amnésie sur ce qui se fait ailleurs qu'on doit les suivre dans cette célébration du "centenaire de l'aviation".
C'est le centenaire d'un étape importante, mais pas le centenaire de toute l'aviation tout court.
# Re: google...
Posté par Jllc . En réponse au journal google.... Évalué à 5.
Doit se retourner dans sa tombe le pauvre Clément Ader et son Eole de 1890 (suivie de Avion II et Avion III quelques années après).
[^] # Re: Et pourquoi pas à Gnome/GTK ?
Posté par Jllc . En réponse à la dépêche Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE. Évalué à 1.
A ma connaissance, on retrouve toujours les mêmes widgets (boutons, menu, listes, conteneurs ...) fonctionnant toujours sur le même principe. Pour organiser l'interface, on imbrique les conteneurs, les mêmes widgets ont toujours les mêmes propriétés (label dans un bouton ..). Après, selon le toolkit utilisé, c'est plus ou moins rapide, plus ou moins gourmand en mémoire, plus ou moins joli ...
La réponse semble oui puisque chaque projet multi-plateforme (Mozilla, OpenOffice) refait sa propre moulinette, mais je ne comprends pas pouquoi.
[^] # Re: Vos avis sur les appareils photo numérique (fonctionnant sous Linux)
Posté par Jllc . En réponse au journal Vos avis sur les appareils photo numérique (fonctionnant sous Linux). Évalué à 1.
Point très important la consommation électrique. Pendant les premières semaines, les économies en pellicules/développement sont parties dans les piles. Il faut donc prévoir des piles rechargeables et un bon chargeur. Conseil : avoir 2 jeux de piles (l'un charge pendant que l'autre sert) pour ceux qui photographient beaucoup.
Toujours pour les piles, je peux dire après 2 ans d'expérience que les piles rechargeables ne tiennent pas les milles recharges promises. J'ai un jeu de piles moisies (oxydées) et l'autre tient très mal la charge. Il faut donc bien choisir ses piles et le chargeur. D'après ce que j'ai lu, il y a des chargeurs "intelligent" qui déchargent proprement les piles avant une nouvelle charge (pour éviter l'effet mémoire) et qui contrôlent séparemment la charge des piles branchées dessus, afin de faire ça au mieux. Par contre, je n'ai pas de marque/modèle à conseiller.