ESR gueule car il a fait un "rpm -e --nodeps lib_essentielle_pour_rpm". Il a forcément fait un "--nodeps" car c'est une librairie qui est utilisé et les dépendances de librairie sont calculée automatiquement par rpm. Après rpm ne marchait plus. Et donc après il gueule car il n'y a pas de version static de rpm dans Fedora. Il a fait une connerie, il assume. Le jour où il fait "rm -f /bin/rpm_static" il va gueuler car il n'y a pas /bin/rpm_static_au_secours pour les con qui virent /bin/rpm_static.
Et ESR est de mauvaise fois car il sait comment récupérer ce type de connerie. Il suffit de booter avec le CD-ROM ou d'utiliser une installation parallèle.
Le problème, s'il y en un, ce n'est pas rpm. C'est le contrôle des dépôts. Ça n'a rien à voir avec rpm ou deb.
Autre chose. Beaucoup qui utilisent Fedora ajoutent plein de dépôt qui sont, et c'est très souvent indiqué, incompatibles avec Fedora Extras. Mais en même temps ils ont Fedora Extras. Au final ça ne peut que exploser. Et passer à deb ne change rien à ce problème. Sans compter que deb ne supporte pas multilib, ne supporte pas SeLinux, etc...
L'autre problème classique, c'est un mirroir qui n'est pas à jour. Par exemple Fedora Extras est mise à jour (passe une libtoto-1.2 à libtoto-1.4) et dans l'heure livna est mis à jour pour utiliser libtoto-1.4. Manque de change lorsque l'utilisateur fait "yum update" alors que son mirroir Fedora Extras n'est pas à jours. Donc yum dit qu'il manque libtoto-1.4 pour faire la mise à jour (et il a raison). Dans ce cas, il faut faire sont "yum update" le lendemain et c'est tout. L'échec du "yum update" précédent est sans conséquence.
Ce problème on l'a aussi avec deb.
Un fois qu'on enlève ces problèmes classiques qui n'ont rien à voir avec rpm et où deb n'est en rien une solution, il n'y a pas de problème avec une Fedora stable. Ou alors c'est exceptionnel (genre une fois tous les 3 mois) et sans conséquence (puisque la mise à jour est refusée).
Pour F7, il y aura un contrôle systèmatique (via un programme qui contrôle les dépendances d'un dépôt). Par exemple un paquet ne pourra être mise en "update" s'il casse des dépendances. Ceci n'a rien à voir avec rpm.
NB : F7 aura les dépendances de contrôlé pour "feu" Fedora Core et Fedora Extras. F7 ne va pas contrôler les dépendances de Freshrpms ou Livna par exemple.
>> Dans les OS "le moins utilisé" il y a Mac. Ben Mac a peu de soucis de sécurité.
>
> Ben faut mieux regarder, ils ont tout un tas de failles de securite eux aussi.
Des trous de sécurité qui ont coûté des milliards comme Windows ?
Me fais pas rire. Et rapporte aussi au nombre de poste (à la popularité), Mac n'est pas la catastrophe Windows.
> Au hasard tu peux donner ton propre systeme d'authentification(qui permet de faire authentification biometrique, smart card, ... ou n'importe quoi auquel tu pourrais penser)
Oui, ça existe sous Linux. Je n'en suis pas fan. RHEL le fournit.
Alors que je te demande un add-on équivalent de SeLinux, tu réponds répond par ce qui pourrait être un module PAM.
> IE7 par contre, il ne peut acceder a rien a part le repertoire cache, et un autre repertoire je crois.
Ben tant mieux si MS se met enfin à faire des trucs sûrs.
> > Non seulement il te le donne, mais tu peux aussi le changer. Que du bonheur...
>
> Tu m'expliqueras comment faire, je suis interesse
Menu : Tools | Internet Options...
Onglet : Sécurité.
> Donc tout ce qui n'est pas _necessaire_ est une arnaque ? Ta montre est une arnaque? Non c'est bien ce que je pensais.
Tu achètes un antivirus pour faire joli ? Pour écouter de la musique ?
Pourquoi pas, si c'est joli et que la musique est bonne.
Pourquoi tu achetes un antivirus au fait ?
Car c'est utile/nécessaire ou pour faire joli ?
> Un anti-virus tu l'achetes car tu n'es pas capable de savoir si il est sur de lancer cet executable inconnu qu'un site web te propose.
La bonne excuse...
Les virus qui ont coûté des milliards à l'industrie et ont foutu la panique jusqu'à passer au 20 h de tf1 et en boucle sur france info, c'est car les gens downloade explicitement un programme et le lance explicitement.
Mais oui...
> Vu que Windows est utilise par des gens ne connaissant rien a l'informatique et susceptible de lancer tout et n'importe quoi oui.
L'utilisateur de Windows a besoin d'un BigBrother. L'utilisateur de Windows est un con qui lance tout et n'importe quoi.
> Maintenant je serais ravi que tu me prouves, car tu ne l'as toujours pas fait, la difference architecturale entre Windows et Linux qui fait qu'un anti-virus est _necessaire_ sur l'un et pas l'autre.
En simpliant tout à l'extrème comme tu le fais, alors oui "la difference architecturale entre Windows et Linux" est nulle.
Mais à part la popularité de Windows, tu n'as pas avancé l'ombre d'un embroyon d'explication sur le FAIT que Windows a coûté des milliards en virus et attaques en tout genre, ni que Windows a besoin d'un antivirus (à part dire que les utilisateurs de Windows sont des cons contrairement aux utilisateurs de Linux (merci pour ces derniers)).
Quand Linux sera populaire (20 % des postes) et qu'il aura pas d'antivirus ni de problèmes qui coûtent des milliards, je serais très curieux de voir ton explication. Je sens qu'il va falloir se contenter d'un "Windows n'a eu de chance".
> Je sais pas, tout comme toi, mais disons qu'une societe a des raisons d'augmenter ses chiffres, IDC un peu moins.
Les chiffres de Red Hat sont des chiffres comptables. De plus Red Hat étant en bourse ils sont vérifiables. Là tu dis que Red Hat magouille et tu pousses le bouchon un peu loin si tu n'as aucune preuve. Et si t'en as, lance des poursuites contre Red Hat. Tu es sûr de gagner et tu auras la bénédictions des actionnaires de Red Hat.
> IDC un peu moins.
Je n'ai pas remis en cause l'honnêteté d'IDC dans cette étude.
Cherches openoffice, tu le trouveras en 64 bits. Ce n'est qu'un exemple.
Ceci dit, c'est récent. Mais Openoffice est aussi dispo sur Sparc depuis longtemps.
> a) Tout n'est pas dispo en 64bit sur Linux, loin de la
Ouais, il manque flash.
Tout n'est pas dispo en 64 bit sur Linux. Seulement 99,9 %.
> b) Tu me montres la difference des APIs entre 32bit et 64bit sur Windows ? Je t'aides, t'auras du mal.
Ben si tout nickel (au moins autant que Linux), MS-Office en 64 bits ne coûte rien à faire et devrait déjà être là !
Alors pourquoi il n'y a pas de MS-Office en 64 bits alors que depuis Windows NT il y a une version de Windows en 64 bits ?
Si Fedora/OOo (idem pour RHEL le produit commercial avec support et tout) le fait, j'ai énormément de difficulté à comprendre pourquoi Windows ne le fait pas si selon toi il n'y a aucune difficulté. Et notes bien que les moyens de Microsoft n'ont rien à voir avec les moyens ridicules de Red Hat à côté.
> Quand a Office, ben pour la meme raison qu'OpenOffice faut croire...
Sauf qu'il y a tout dedans. Et pour PowerPPC, c'est 64 bits.
De plus, je n'ai pas souvenir que Windows a une version AMD64 ! J'ai seulement entendu parlé de versions béta et qu'il y a une version AMD64 pour Vista. C'est donc très récent. Quand on connait les moyens de Windows, si tu affirmes qu'il n'y a pas de problème pour MS de fournir du 64 bits, on a un sérieux problème de logique dans ce que tu dis.
Pour info, AMD64 (en vrai 64 bits) est dispo depuis RHEL 3 (avec support et tout et plein de programme). Et pour une version de Linux en 64 bits (avec 99,9% des logiciels) il faut remonter à la nuit des temps.
M'enfin, continu d'affirmer que windows est aussi portable que Linux.
> Windows supporte UTF-16 depuis un moment deja(depuis XP en tout cas), ca fait 6 ans...
Ben je n'ai vu que ucs-2.
> ca fait 6 ans...
Ce qui est du pipo. Windows est passé à ucs-2 avec Windows NT (ou 2000?). Et je dis bien ucs-2 (2^16 caractères) et non utf-8 (2^32 caractères). Windows 2000 utilise ucs-2 (j'en mettrais ma main au feu) et XP n'est qu'une évolution de Windows 2000.
> Par contre plein de boites prennent leur ancien code 16bit et veulent le recompiler en 32bit, et la ca rend les choses bcp plus simples vu qu'ils n'auront quasiment pas a changer leur code.
+1 pour toi. Même si je trouve que c'est de la connerie à moyen/long terme.
> Il n'y a pas de PID pour les threads sous Windows, il y a un thread ID
Oui. Désolé d'avoir dit PID.
> Linux a un Process ID pour des threads, alors que ce sont des threads, pas des process, tu m'expliqueras la logique.
Linux a :
- Process ID pour les thread : c'est le même pour tous les thread d'un processus (normal, tous thread appartient à un processus). Le thread n'a pas cette information directement attaché à lui.
- Thread ID pour chaque thread : Le type n'est pas pid_t mais pthread_t
J'espère que tu vois maintenant la logique évidente.
C'est comme ça pour LinuxThread et NPTL.
Par contre au niveau noyau (chose dont n'a pas à se préoccuper le développeur), les numéros de processus (pid_t) et de thread (pthread_t) sont partagés. Le premier thread d'un processus a pthread_t = pid_t. Pour les autres pthread_t != pid_t (quelque soit le thread et le processus). Mais ça le développeur s'en fout. Si un jour Linux change ça, il n'y aura pas de problème de portabilité (sauf pour les applis codé avec les pieds).
> Pour les APIs multithread, de nouveau, c'est parece que tu ne comprends rien a l'architecture de Windows.
Tu serais gentil d'arrêter de me prendre pour un con.
> Tu fais comment pour attendre sur un event, un timer, la fin d'un thread, ... sous Linux ? Ah oui, des APIs differents, sous Windows, tous ces elements sont des objets, et tu utilises WaitForSingleObject.
+0,1 pour toi. Mais Windows a encore mieux et ça on ne le trouve pas sous Linux :-)
C'est WaitForMultiObject et notamment avec l'option "auto-reset". Avec les mutex c'est intéressant, d'autant plus que c'est atomic. On peut le simuler sous Linux mais ce n'est pas trivial.
> Sous Windows, personne n'utilises le modele "plusieurs processus"
Ce qui est de la connerie. Le modèle "plusieurs processus" a ses avantages et idem pour le multi-threading.
Le gros problème du multi-threading est que le plantage d'un thread fait planter pour le processus. Et c'est la même chose sous Windows.
Alors que Windows fasse un gros processus. Les autres programmes (stockés dans des dll) seront dans des threads. C'est techniquement tout à fait réalisable. Mais dès qu'un truc plante, tout plante. Et il me semble bien que Windows fournit un truc style "job control" pour "mimer" Unix. Les "jobs" sont des processus et non des thread.
Donc ne dit pas que "Sous Windows, personne n'utilises le modele "plusieurs processus"" car c'est absolument faux.
> sous Unix c'est frequent car jusqu'a recemment le support des threads etait a chier
Rires. Tous les Unix commerciaux ont du multi-thread depuis longtemps. Il n'y a que Linux qui a mis du temps car Linux a débuté en 91 (il était embryonnaire). La version 2.0 de Linux avait le multi-thread. Linux 2.0 est sorti quasiment en même temps que Windows 95/NT (en fait Linux l'avait pour la version 1.2.13 mais pas pour 1.2.0). Donc Windows n'a pas le multi-threading depuis plus longtemps que Linux et assurément pas avant les Unix commerciaux. Le seul problème de Linux est que durant assez longtemps il n'avait pas de thread au niveau noyau. C'est-à-dire que ça ne permettait pas de tirer profit des systèmes multi-cpu. Mais sur la bécane de messieur tout le monde on a rarement du multi-cpu (et même sur la majorité des serveurs).
Notons que les gains de performance du multi-thread sur le multi-processus n'est pas énorme (et souvent nul). D'autant plus que créer un processus sous Linux n'est pas cher (fork() ou clone()).
On a vu plusieurs projet forker un projet pour le passer en multi-thread sans qu'il y ait de gain.
> le support des threads etait a chier
C'est-à-dire ? Depuis Linux 2.0 le multi-thread est Posix. Il n'était pas parfaitement Posix mais à 98 % Posix. NTPL l'a rendu 100% Posix (ou 99,9 %). C'est ce qui a permis aux applications Linux de passer rapidement de LinuxThread à NPTL.
Exemple : Il y avait LinuxThead et NPTL dans RHEL 3. Il n'y a que NPTL dans RHEL 4. Pourtant fournir LinuxThread en parallèle n'est pas un problème. Mais porter les applications vers NPTL n'est pas un problème non plus.
Donc si tu dis que le multithread était à chier, il doit l'être encore aujourd'hui selon toi.
L'intérêt de NPTL n'était pas de passer d'un multi-thread à chié à un truc formidable. Mais d'avoir le multi-threading en mode noyau et être plus conforme Posix. C'est tout, bien que la tâche n'a pas été évidente.
NPTL a des avantages significatif dans le cas où on a plus de 50 ou 100 thread. Ça ne conserne pas la majorité des applications, c'est le moins qu'on puisse dire.
> resultat, tout le monde utilise les CRITICAL_SECTION
Je ne vois pas le rapport. Je n'ai pas dit que CRITICAL_SECTION était mauvais. Je parlais de l'API. Relis.
> Un block memoire ? Tu fais ca comment pour avoir un HANDLE sur un block memoire ?
CreateFileMapping() par exemple.
Mais je suis mauvaise langue.
Je me suis trompé.
Il y a (si j'ai bonne mémoire) LocalAlloc qui retourne un HLOCAL et j'ai conclus rapidement qu'un GlobalAlloc retourne un HANDLE alors qu'il retourne un HGLOBAL (si j'ai bonne mémoire).
Retourner un (void *) comme tout le monde ça aurait été trop simple...
> tu peux attendre sur tous ces objets avec le meme API. Bien plus simple que les 32 APIs differents pour faire la meme chose sous Linux.
C'est une façon de voir la chose. Mais il n'y a aucun contrôle de type. Le seul intérêt des HANDLE est le WaitFor*Object(). C'est tout.
De plus WaitForSimgleObject ne marche pas pour tout. Il marche que pour attendre la fin d'un timer, la fin d'un thread, etc. Mais un WaitForSem() qui attend qu'un sémaphore passe à 10 ça n'existe pas.
Vu la contrepartie, je trouve ça sans intérêt. Par contre WaitForMultiObject (ou WaitForMultipleObject ?) c'est cool.
Sous Linux pour attendre la fin d'un thread on fait pthread_join(pthread_t, void **). Ce n'est pas la mer à boire, c'est lisible.
Donc on a des api qui exige spécifiquement du uint32...
Sous Linux on n'a pas ça. On a pid_t qui on une taille qui colle au hardware ou au besoin de la fonction. Mais on ne dit pas qu'un pid_t doit être un uint32. Un jour c'est un int16, un autre c'est un int32, on s'en fout. Il y a toujours des exceptions. Mais tant qu'elles sont rares, ça se gère. Sous Windows l'exception est la règle.
> mais visiblement tu ne lis pas la doc, dans ce cas pas etonnant que tu n'y comprennes rien.
J'en ai lu beaucoup sur Windows ce dernier mois.
> Plutot que dire que c'est pour des conneries, et si tu donnais des exemples ou c'est inutile ?
Le wchar_t je vois l'intérêt. Le WCHAR pourquoi pas. Mais les LPCWSTR, etc c'est stupide et ça n'améliore pas la lecture du code (il faut connaitre une tripoté de typedef).
Donc Windows ne support que ucs-2. Merci d'en faire la démonstration.
Tu me traites de con qui ne sait pas lire la doc. Je bosse sur Windows en tant que développeur depuis 1 mois seulement. Toi ça fait depuis des années et tu ne sais toujours pas que Windows ne supporte que ucs-2 et pas UTF-8. UTF-8 est une façon de coder usc-4 (unicode) et a 2^32 valeurs. Ça ne rentre pas dans du 16 bits. wchar_t sous Linux est dans son implémentation actuelle du 32 bits. wchar_t n'est pas défini comme étant un int32, mais comme étant un wide caractère. Qu'il occupe 8, 16, 24 ou 32 bits, n'est pas une propriété que le développeur doit utiliser ni savoir (sauf pour débuggeur).
Avec la définition qu'a Windows de wchar_t, ça ne va pas être facile de passer à usc-4...
> Tout comme sous Windows, mais ton probleme c'est que tu n'y connais rien et en parles quand meme.
Très bien, fais ce que tu dis et arrêtes de parler du logiciel libre.
Enfin, je tiens à te signalé que j'ai parlé de l'API de Windows après m'être informé. J'en parlais pour expliquer pourquoi "Linux tient tête à Windows" alors que Windows a facilement 100 fois plus de développeur que Linux.
M'enfin, tu as peut-être une autre explication. Les développeurs Linux seraient 100 plus doués que les développeurs Windows ?
Il y a moins d'un mois, je n'aurai rien dit de l'API de Windows et j'en ai rien dit jusqu'à ce que je lise la doc.
Si j'étais un anti-Windows primaire, je n'aurais pas dit que l'API de Direct3D est bien foutue ni que le noyau de Windows offre toutes les fonctionnalités qu'on attend d'un OS moderne.
De plus, j'ai passé sous silence DirectShow alors que ça va devenir mon "coeur de métier". En un mot : lourdingue. Tellement lourdingue que MS fournit une tripoté de classe pour simplifier le développement. Mais comme ces classes ne répondent pas à mon besoin... ça va être lourdingue.
Mais DirectShow est bien moins pire que l'API de Windows. Son historique l'a rendu lourdingue. M'enfin, il n'y a pas vraiment d'équivalent dans le libre. Sauf gstreamer mais ce n'est pas encore ça ; espérons que ça ne tarde pas.
NB : gstreamer est beaucoup plus récent que DirectShow. Je dis ça avec que tu te foutes de gstreamer.
Quelles souvenirs de l'époque où je lisais les mailings Fedora.
ESR n'est pas vraiment un homme de compromis, il n'aime pas "se fondre dans le moule" ou adhérer à un mouvement qui ne lui satisfait pas pleinement. Il a un fort caractère et peste souvent. En caricaturant il se prend pour une star... C'était un bon contributeur, mais sans plus. Mais il demande à Fedora ce que Fedora n'est pas. http://www.redhat.com/archives/fedora-devel-list/2007-Februa(...)
Canonical's recent deal with Linspire, which will give Linux users legal access to WMF and other key proprietary codecs, is precisely the sort of thing Red-Hat/Fedora could and should have taken the lead in.
Fedora n'est pas ça et ne veut pas ça. Fedora n'empêchera jamais personne de le faire, mais hors du projet Fedora. Il y aura peut-être une Fedora-Windows avec les codecs Windows en payant. Fedora ne l'empêchera pas. Mais la Fedora-Windows ne sera pas sous le chapeau du projet Fedora.
C'est peut-être prétentieux, mais Fedora veux être aux distributions (à l'OS GNU/Linux) ce que Linux est au noyau. Linux donne la cadence et ne s'adapte pas aux exigences non techniquement justifiées des drivers proprio. Linux est libre, libre de ses choix/évolutions. Pas de compromis dans ce domaine. D'où Linux qui casse souvent la compatiblité au grand désespoire de NVidia ou VMware (voir par exemple l'adoption de kvm et non de la solution binaire de VMware).
Nobody ever said it "should" be a major desktop alternative or play mp3s. The goal of Fedora is "..the rapid progress of free and open source software and content". Fedora "allows" you to do what you want with it, it's not everything to everyone and doesn't try to be.
ESR exige quelque chose d'incompatible avec le projet Fedora.
Bonne route à ESR. Mais je crois qu'il sera aussi déçu par Ubuntu. J'ai le sentiment qu'il ne peut jamais être satisfait.
> De meme, IE ne demande absolument pas les droits d'admin pour tourner, il tourne tout a fait normalement en user.
Admettons mais j'en doute puissament.
> Quel rapport avec l'OS et son architecture ? Si demain j'ecris un browser qui supporte ActiveX sous Linux, Linux devient mauvais architecturalement ?
Essais de proposer un brower avec ActiveX. Aucune distribution le fournira (sauf si MS fait une distribution Linux...).
> Justement, c'est toi qui interprete mal, l'OS le plus utilise est le plus attaque, ca ne veut absolument pas dire qu'il est le moins fout niveau securite, et rien ne prouve que l'OS le moins utilise soit le mieux foutu.
Dans les OS "le moins utilisé" il y a Mac. Ben Mac a peu de soucis de sécurité. Puis de tout manière dans quelque années Linux sera très utilisé (10 %) et on verra que cette esplication avec la popularité de Windows est du flan. A 10 % tu va dire que ce n'est pas assez. Ben on attendra que Linux soit à 90 % et ça sera encore le cas. Linux ne sera pas la catastrophe Windows (à 0,1 % de popularité comme à 99,9 %).
Si Windows était un OS "super secure" comme le dit la propagande, pourquoi il supporte si mal sa "popularité" ?
Si Linux est si naze, pourquoi dans la pratique il est si "secure" ?
Tu ne pourrais pas faire un petit virus pour Linux ou cracker Linux histoire de démontrer que linux n'est pas "secure". Un truc qui fait du bruit. Et si ce n'est toi, pourquoi pas un autre fan de Windows ?
Il parait que beaucoup de cracker Windows tourne sous Linux. Pourquoi pas l'inverse ? Et pourquoi il n'y a pas l'inverse ?
Beaucoup de gens détestent Windows. Mais comme il y a beaucoup d'utilisateur de Windows, on peut penser qu'il y a beaucoup de fan de Windows. Je me trompe ?
> Et sous Windows t'as les comptes LocalSystem, NetworkService, ....
Et le compte Service. Je crois que tu as avoir du mal pour en trouver d'autres.
> De nouveau, manque de connaissance total de Windows, il y a plein d'add-ons dispo
Par exemple ?
Je ne parle pas d'outil d'audit. Je parle d'add-on actif (comme SeLinux).
> ActiveX est inoffensif dans Vista
Il aura fallu attentre VIsta... Des années.
M'enfin, méfiance, à la sortie d'XP, XP était "secure" selon MS et résolvait tous les problèmes de sécurité des versions précédentes de Windows. L'histoire a jugé, et XP était naze.
> vu qu'IE tourne avec quasi-aucun droits
Tiens maintenant il "tourne avec quasi-aucun droits" alors que plus haut c'était sans aucun droit...
> quand au niveau de securite, IE te le donne, faut mieux regarder.
Non seulement il te le donne, mais tu peux aussi le changer. Que du bonheur...
> J'attends une explication sur quels problemes de securite dans _WINDOWS_ demandent un anti-virus, et en passant, MS ne donne pas d'anti-virus avec l'OS, c'est un achat separe pour ceux qui en veulent, ce n'est nullement necessaire.
Si ce n'est pas nécessaire, c'est alors une arnaque. Rires^W heu non, ce n'est pas rigolo. Microsoft arnaque les gens en vendant un antivirus.
Au fait, ce n'est pas MS qui fait tout pour qu'on ne puisse pas retirer IE du système ? IE qui est installé avec _WINDOWS_. Ce n'est pas MS qui clame haut et fort que IE fait parti intégrante de l'OS de _WINDOWS_ ?
Oui et oui. J'y peux rien, c'est MS qui le dit.
Au fait, ce n'est pas Windows lui même qui te conseil d'installer un anti-virus ?
Oui, le "Security Center" de _WINDOWS_, même quand je n'ai installé que _WINDOWS_, me le conseil ! Idem s'il n'y a que du Microsoft certified Geniune, etc, _WINDOWS_ me conseille d'installer un antivirus (sinon je met en péril mon système (dexit Windows)).
C'est n'est pas MS-Office (ou Acroreader, etc...) qui me conseille d'installer un anti-virus, c'est _WINDOWS_.
Un autre truc rigolo (limité à redhat.com) : http://www.google.fr/search?hl=fr&q=site%3Aredhat.com+an(...)
5 430 pages avec "antivirus" ! Mais je te laisse regarder les pages. Ça parle quasi exclusivement d'antivirus pour Windows... et rien pour Linux.
Le libre n'est pas le communisme. Pour le communisme la liberté est accessoire.
Politiquement parlent, le libre est plus proche du libéralisme que du communisme.
> Rien a voir, car ils ne parlent pas de la meme chose, au niveau securite les 2 ont :
> a) separation user / kernel
> b) separation entre users
> c) notion d'administrateur / user avec acces limite
>
> Bref, architecturalement parlant, ils sont quasi-identiques la dessus.
J'avais raté ce grand moment...
Ta description est simpliste. Tellement simpliste que tous les OS multi-utilisateur la respecte.
Mais sous Windows il n'y a qu'une partie du système qui est protégée. Tu peux faire un "rm -r -f /" sous un compte avec Linux, il n'y a que ton compte qui est bousillé. Sous Linux, et n'importe quel OS respectable, c'est l'ensemble du système qui est protégé. L'utilisateur n'a pas un navigateur qui tourne sous le compte administrator comme Windows le fait et te demande s'il peut faire tel ou tel truc dangereux pour le système.
Impact :
Sous Linux on ne demande pas à l'utilisateur :
- voulez-vous faire ce truc dangereux ?
Sous Linux il ne peut pas et point barre.
Sous Linux il n'y a pas qu'un compte admin mais plusieurs. Le compte bin, mail, dbus, ftp, lp, postgres, etc...
Puis ça ne s'arrête pas à l'OS. Firefox/Thunderbird ne supporte pas ActiveX car c'est dangereux. IE/Outlook supporte ActiveX. L'un veut être sûr et l'autre semble s'en foutre royalement. Opera et Firefox n'ont pas de problème de sécurité (mais des bugs qui sont vites corrigés), IE a des problèmes de sécurité au niveau conception. IE a besoin d'un antivirus, les autres non.
J'imagine que tu vas encore dire que Windows est beaucoup plus utilisé que Linux et donc a plus d'attaque, etc...
C'est marrant que l'OS le plus utilisé, qui a le plus de ressource, soit le moins bien foutu niveau sécurité et que les OS les moins utilisés soient les mieux foutu niveau sécurité.
Tu m'expliques ?
Linux propose plein de add-on au système de sécurité par défaut pourtant robuste. Le plus connu est SeLinux. Pour Windows c'est un anti-virus...
Oui, si on est simpliste, Linux et Windows c'est la même chose. Mais si on gratte ça n'a pas grand chose à voir aussi bien technologiquement que par leur approche de la sécurité. Par exemple ne pas avoir d'ActiveX dans un navigeur, ne pas avoir un onglet d'option pour dire à quel niveau de sécurité on navige, etc...
Linux (idem pour Firefox, etc) n'hésite pas à casser la compatibilité s'il y a un problème de sécurité. Windows le fait en dernier recours et s'appuis sur les anti-virus. Anti-virus tellement indispensable de part la conception de l'OS que MS en propose un maintenant... La boucle est bouclée.
> Si j'en crois les statistiques, il etait deja a 2-3% il y a 2-3 ans(ils parlaient de Linux passant le Mac), hors rien ne montre qu'il soit alle plus loin, d'ou le "manque de decollage" de mon point de vue.
D'accord. M'enfin, les stats ça change du jours au lendemain.
Exemple, au-dessus tu dis (sur la base d'une étude) que Linux a crû de 6.1 %. Sur la même période, le plus gros vendeur Linux fait du +40 % (chiffre absolu) !
Qui croire ?
Autre aspect a remarquer. Linux a été vite adopté par les geeks en tant que desktop (d'où une croissance rapide). Pour les geek, la partie est "gagnée". Je veux dire que Linux n'est plus une alternative exotique. Un geek qui utilise Linux, ça n'étonne personne. Au pif et sans le moindre chiffre, je dirais que Linux à 20 % des geeks ou hackers. Par contre en poste desktop pour monsieur tout le monde (la très grande majorité), c'est une tout autre histoire. Pour Linux y a, au pif et sans le moindre chiffre, 0,1 %. Donc pour arriver à 10 % il faut ... 16 ans.
> Le probleme c'est que les editeurs n'en ont rien a battre du 64bit jusqu'a ce qu'il commence a se repandre, le meme probleme que Linux a avec les editeurs.
Mais pourquoi les éditeurs (oracle, ibm, etc) font des versions 64 bits pour Linux et pas pour Windows ?
> MS met son poids dans la balance pour changer ca(Exchange 2007 est 64bits uniquement par exemple) mais ca prend du temps.
Il y a MS-Office en 64 bits ? Je n'en sais rien mais je ne crois pas.
Mais il y a bien openoffice en 64 bits pour Linux et il n'y a pas de version 64 bits pour Windows d'Openoffice.
Le fait est là, Linux à tout (ou 99,9 %) en 64 bits et Windows pas grand chose.
> le meme probleme que Linux a avec les editeurs.
Les éditeurs Linux font du 64 bits. Tu nous dis que Linux a gagné la partie pour le 64 bits ?
> Tout a fait, mais moi je parles techniquement, NT n'avait aucun probleme a passer a 64bits techniquement.
Ce que j'ai surtout voulu dire est que l'API (ce qui est vu par les programmes) sucks et rend difficile le portage d'une appli 32 bits vers 64 bits ce qui n'est pas le cas de Linux.
S'il est facile d'avoir des applis 64 bits sous Windows, pourquoi il n'y a pas MS-Office (j'imagine qu'il n'y a pas MS-Office en 64 bits, car en fait je n'en sais rien) ?
Linux a des ressources ridicules par rapport à Windows et pourtant tout est dispo en 64 bits.
> Combien est-ce que Redhat fait de chiffre d'affaire sur PPC et autres ? Rien du tout,
On dit que tu as raison. Mais si ça ne coute "rien du tout" à Red Hat d'avoir une version 64 bits, ils auraient tord de ne pas proposer du 64 bits. Si ça coute "rien du tout" pour avoir du 64 bits sous Linux, alors Linux est vachement bien foutu. Si ça coutait cher, Red Hat auraient tord de faire du 64 bits (surtout que Red Hat est ridicule à côté de MS) et ça fait depuis longtemps qu'ils auraient arrêté de le faire. Si Red Hat le fait, c'est qu'il y voir un intérêt et en monnai sonnante et trébuchante. Mais clairement Red Hat ne doit pas perdre d'argent.
Red Hat vend beaucoup de 64 bits. D'ailleurs pour RHEL 5 il y aura encore le support pour IA64 (ce qui montre que Red Hat a beaucoup vendu de RHEL 3 et 4 pour IA64).
> In what follows I investigate the state of UTF-8 support under Linux (especially Debian
Debian est l'un des derniers distribution a être passé à UTF-8 !
Red Hat est passé à UTF-8 depuis la Red Hat 8.0 ! C'est configuré par défaut depuis RHL 8.0. Puis il y a eu RHL 9, FC1, FC2, FC3, FC4, FC5 et FC6. Il n'y a pas encore eu de Debian stable en UTF-8 ! (OK, ça ne devrait pas tarder).
Aussi, RHEL utilise UTF-8 par défaut depuis RHEL 3.
Autre chose, Linux support UTF-8 (donc 2^32 caractères, c'est-à-dire tout unicode). Windows (et si mes renseignement sont bons) que UCS-2 (2^16 caractères). UCS-2 est insuffisant pour certain language (c'est pour ça que Unicode est passé à 2^32).
Sous Linux en mode texte ça concerne la libc. En mode graphique ça concerne principalement gtk (pango). Malheureusement OpenOffice ne supporte pas pango et Mozilla que via un patch non officiel (qui marche bien mais impact significativement les performances). Le patch est dans Fedora depuis FC2 (pour Mozilla) et activé par défaut depuis FC3.
Notons que Firefox est principalement développé pour Windows (normal, il y a beaucoup plus d'utilisateur).
Ceci dit le support d'Unicode est une tâche énorme (avec les problèmes lorsqu'on mixe des écritures de gauche à droite et droite à gauche, par exemple, etc...), donc qu'il y ait des problèmes ne m'étonne pas.
> Les MFCs sont moches
Tu me fous la trouille. Je n'ai pas encore regardé MFC. Mais si MFC est pire que le reste, ça fous vraiment la trouille.
> HINSTANCE et HMODULE sont identiques(les 2 existent pour des raisons de compatibilite avec Windows 16bit)
Ben les deux sont dans le dernier SDK platform de Windows... (de 2006).
Je ne crois pas que quelqu'un va installer le dernier SDK de Windows pour faire une application 16 bit.
Ces trucs ne sont qu'un pointeur sur l'adresse du début du programme ou dll. Tout un poème.
> L'API il t'es difficile a retenir parce que tu debutes
Non. Par exemple DirectX, plus spécifiquement Direct3D, passe très bien. Et pourtant j'y connaissais rien dans le domaine des cartes graphiques.
Exemple : Dans Linux tout ce qui est thread débute par pthread. Sous Windows c'est une autre histoire.
Sous Linux il n'y a que le pid du thread. Sous Windows il y a l'HANDLE et le pid (parfois nécessaire pour quelques fonctions).
Regardes les fonctions liés à la mémoire sous Windows et compare avec Linux. T'as même un LOCALHANDLE... Des relant de Windows 16 bits dans le dernier SDK de Windows...
Pour le multi thread il y a les CRITICAL_SECTION/EnterCriticalSection/LeaveCriticalSection mais ça ne marche que pour un processus. En interprocessus, il faut autre chose (via les Event). Sous Linux, c'est la même chose pour intro-process et inter-process, tu dis seulement si tu veux que ça marche en inter-process (donc passage par le noyau systèmatique) ou non. C'est tout. La librairie C fait les appels système qui vont bien dernière. Si tu veux passer d'un processus à plusieurs, ça se passe comme une lettre à la poste.
> c'est l'utilite des typedefs: le compilo t'avertira si tu passes un HANDLE a une fonction qui veut un HINSTANCE.
C'est gentil ça. Un timer (event) et un process a le même type sous Windows. En fait tous les "objects systèmes", selon la terminologie MS, a le type HANDLE. Tu peux passer un timer ou un block mémoire à la place d'un process ou d'un fichier, le compilo ne voit aucun problème. Ce n'est en rien le cas sous Linux et fort heureusement.
Les typedefs Windows en utilise des tonnes et pour des conneries. Par exemple pour char il y en a plus d'une dizaine !
Linux utilise beaucoup de typedef (probablement plus que Windows) mais pas pour des conneries (comme DWORD qu'on trouve partout ce qui doit poser de gros problème de portabilité). Linux utilise des typedef là où c'est pertinant : quand le concèpt est différent. Un pid même si c'est stocké réellement dans un int (DWORD dans le language Windows) n'est pas un int, pour des raisons de portabilité, d'évolution système (lorsque le pid passe de 16 bits à 32), etc.
Autre chose rigolote, c'est DWORD. C'est un int ou un long ? Ben je crois que même MS n'en sait rien. Ce n'est pas un problème en soit. Surtout que sur du 32 bits int=long. Mais pour 64 bits on peu avoir par exemple sizeof(int) = 4 et sizeof(long) = 8. Donc le diff de deux pointeurs ou une taille mémoire n'est plus un int (DWORD) mais un long. Ben avec tous les DWORD dans l'API de Windows qui désigne des concepts différents (nombre, quantité de mémoire, etc), ça doit foutre un sacré bordel.
Linux (en fait POSIX) n'a pas ce problème. Si tu codes correctement, passer de 32 bits à 64 bits (que sizeof(int) soit 4 ou 8, qu'importe), passe comme une lettre à la poste.
Autre problème, Windows semble avoir des conventions de nommage mais elles sont peu respectée. Exemple : utiliser le préfix P pour le pointeur alors que c'est rarement utilisé. Les types qui sont parfois uniquement en majuscule et parfois un mix. Normalement ce qui commence par '_' est à usage interne d'une lib système (une appli ne doit pas l'utiliser !), ben sous Windows pas forcément, etc...
De ce que j'ai vu jusqu'à maintenant il n'y a que Direct3D qui est une bonne API (et pourtant Direct3D est particulièrement complexe ce qui ce comprend très bien).
Quand on sait que les constructeurs de hardware sont très impliqués dans le développement de Direct3D, on comprend que Direct3D n'a pas le "Windows touch".
> Faut pas rever, la variete ca a des avantages(t'as le choix), et ca a des inconvenients(cf ce que je decris).
Je suis assez d'accord.
Mais il faut aller un peu plus loin. Deux implémentations pour le même service c'est sans intérêt, et pire ça peut nuir. Mais par exemple il y a plein de window manager sous Linux. Ça nuit ? Ils n'offrent pas la même chose. Ici c'est du choix pour l'utilisateur, c'est un plus.
Par contre entre gtkmm et qt, c'est limite doublon. M'enfin, qt est utilisé depuis longtemps, utilisé par KDE, et donc restera longtemps. gtk+ et qt n'est pas un doublon. L'un est pour les développeurs C et l'autre pour les développeurs C++. Il y a effectivement quelques doublons dans le logiciel dont l'un des plus populaire est dpkg et rpm.
Un des "problèmes" est qu'il ne faut pas interdire les initiatives même si elle semble faire doublon. Sinon on tu la concurrence.
Puis il faut aussi remarquer que les projets libre ont naturellement tendance à suivre les standards et non réinventer la roue. Les différences ne sont jamais introduites pour rendre les utilisateurs captifs.
> A mon avis son journal ne s'addresse pas a Linus Torvalds, Andrew Morton ou autres mais plutot aux gens qui frequentent ce site.
Je fréquente ce site. Et comme beaucoup ici (même si on n'est peut-être pas la majorité mais on doit être un part significative) je ne dis pas que Linux est au top pour le desktop et va tout déchirer dans les semaines à venir. D'ailleurs des journaux avec "Linux est-il près pour le desktop ?", etc... on en voit des tonnes.
> Tu sais, ces memes gens qui trouvent 3342 excuses pour expliquer pourquoi Linux ne decolle pas
Là tu fais une erreur. Linux décolle. Mais il est parti à 0,01 %. S'il grippe à 33 % par ans (ce qui est fort respectable), il faut plus de 8 ans pour arriver à 0,1 %, et encore 8 ans pour arriver à 1 %, et encore 8 ans pour arriver à 10 %. Donc il faut 24 ans !
Il suffit de bases minimum en mathématique pour savoir ça.
> C'est surtout toi qui ne sais pas du tout ce que MS fait, passer NT a 64bits etait tres simple, ce qui etait plus complique c'etait avoir un support de drivers decent vu qu'on ne les ecrit pas, generer tous les tests necessaires et avoir un support pret pour gerer pour ca.
Ben c'est que je dis. Linux a 64 bits (avec drivers et des tonnes d'applications) depuis longtemps et pas Windows. Il y a une offre pour entreprise en Linux 64 bits. Windows c'est récent.
Pourquoi Windows peine à avoir des applis et des drivers 64 bit ?
Car les éditeurs de logiciel et de driver trainent la pate ? C'est seulement à cause de ça ? Probable que l'API windows sucks car si j'ai bonne mémoire, la version Alpha de Windows tourne en 32 bit pour les int... Alors que le int naturel d'Alpha (son mot machine) est en 64 bit sur les unix (idem pour Linux). C'est juste un exemple...
> De nouveau, rien a voir, tu sais depuis quand MS avait un NT 64bits en interne ? Depuis quand NT supporte les technos VT ? Non, tout ce que tu regardes c'est ce qu'on vend, et les releases elles dependent de bcp d'autres criteres en plus de "c'est pret techniquement".
L'argument est pertinant. Mais je parle d'offres aux entreprises (désolé, je ne l'ai pas signalé plus haut). Je ne parle pas d'un truc qui marche au fond d'une université. Je sais qu'il faut du temps entre l'innovation et son déployement.
Red Hat 7 (voire encore plus vieux) proposait au entreprise i386, Alpha, Mips (peut être plus encore). RHEL 4 propose i386, AMD/Intel 64, PPC32, PPC64 et peut-être encore d'autres.
> Linux ? Qui ca le kernel ? Parce que des softs Linux qui ne gerent pas UTF-8 j'en connais plein
Exemple ?
Xbill ?
Qu'es-ce qui ne supporte pas UTF-8 dans Linux et qui est utilisé ?
Pas grand chose.
> Linux ? Qui ca le kernel ? Parce que des softs Linux qui ne gerent pas UTF-8 j'en connais plein, et un OS c'est legerement plus qu'un kernel.
Et il y a presque rien d'UTF-8 dans le noyau (pour ne pas dire qu'il n'y a rien). À part certains trucs pour les noms de fichiers, les terminaux, et guère plus (et je crois que ça doit être moins ça...). UTF-8 on le trouve en premier dans la libc, pas dans le noyau. Et d'ailleur ça ne doit pas conserner le noyau (à quelques exceptions près).
Clairement quand je parle d'UTF-8, je ne parle pas du noyau. Un noyau sans UTF-8 (si un noyau avec existe) ne doit pas poser de problème pour faire tourner une applie UTF-8.
> L'architecture que propose Linux est quasi-identique a l'architecture de Windows
Diantre, Microsoft, ton maitre, dit que Linux est une technologie de 30 ans et que Windows c'est tout beau tout moderne.
MS c'est trompé, ou c'était encore un gros FUD, ou Linux a rattrapé ses 30 ans de retard en moins de 10 ans ?
Les OS (noyaux) sont proches du hardware donc les OS sont proches pour certaines parties. C'est un fait.
Mais sous Linux on n'a pas de C: D: etc...
Sous Linux il y a les pseudo-terminaux.
Sous Linux il y a select().
Sous Linux il y a les signaux.
Sous Linux il y a etc...
Sous Windows il y a etc... (à toi de remplir cette partie).
Entre un Unix commercial et Linux il n'y a pas beaucoup de différence. Par contre entre Windows et Linux (et les Unix en général) il y a de grosses différences.
Ceci dit, comme je me documente sur Windows, je dois reconnaitre que le noyau de Windows fournit ce qu'on attend d'un OS "moderne". Par contre pour l'API bas niveau (tout ce qui est équivalent à glibc) c'est beurk. Les noms de fonction sont bizarres, il y a des HANDLE (void*) partout, des fonctions qui attendent un HINSTANCE (void *) fournit pas main() (diable, pourquoi la libc de Windows ne gère pas ça !), il y a des structures et des fonctions avec des membres/paramètres réservés, ou il faut la renseigner avec sizeof(struct), etc... Quel est la différence entre un HANDLE un HINSTANCE et HMODULE ?
J'ai rarement (jamais ?) vu API aussi moche. Et c'est diablement difficile à retenir.
Oui oui, on peut...
On peut aussi rendre autoconf dépendant de gcc, de libstdc++, de libxml2, avoir une interface graphique en gtk+ ou qt, etc...
On peut. C'est blindé de dépendances circulaires s'il faut construire depuis les sources "from scratch", mais oui, on peut. Après je ne te dis pas l'enfer que c'est de maintenir une distribution...
> Qu'autoconf serve a compiler gcc n'y change rien, ils s'amusent pas a partir d'une machine nue
Ben avec Gentoo oui (pour donner un exemple).
Autre chose, si tu installes des outils GNU sur un unix commercial, et si autoconf exigerait gcc, etc, alors je ne te raconte pas l'enfer.
Normalement les unix commerciaux ont : shell, awk, sed, m4. Ce que demande autoconf.
> le bootstrap du compilo c'est pour le compilo
Pour le bootstraper gcc, gcc utilise le compilateur fournit par l'unix commercial ou Windows. Gcc n'utilise pas gcc (mais il peut, ce qui se fait avec Linux).
Si j'ai bonne mémoire gcc fait :
cc (compilateur fournit avec l'OS) => gcc stage1
gcc stage 1 => gcc stage 2 (final)
Autoconf fait partit des quelques programmes GNU qui doivent avoir le minimum de dépendance. Idem pour gmake par exemple qui est exigé par beaucoup de projet (NB : gmake n'existe pas gcc).
D'ailleurs sous GNU/Linux ont fait en sorte d'avoir le minimum de dépendance circulaire. Sinon ça pose de gros gros problèmes pour maintenir les distributions.
> Je vois pas ce que autoconf a a voir avec le 64 bits
En un sens tu as raison. Mais les programmes (donc les sources) peuvent avoir besoin de savoir si on est en 32 bits ou 64 bits, s'il faut activer l'option LARGE_FILE (cas 32 bits) ou non, si on est en big ou little endian, etc...
Autoconf fournit ces informations.
Après, il faut aussi que les programmes soient conçu pour 32 bits et 64 bits.
M'enfin quand on voit comme les outils libres tourne sur plein de plateforme/OS, on se dit que c'est aussi grace à autoconf.
> je dirais que c'est plutot grace a gcc.
Pour compiler gcc, gcc utilise autoconf.
> les autotools beuark quoi,
Ben fais mieux. Certe autoconf c'est moche. Mais il faut pouvoir installer et faire tourner autoconf avec trois fois rien. On ne peut pas demander à autoconf d'être écrit en C ou C++ (puisque pour compiler le compilateur il faut autoconf). Actuellement autoconf demande sh, awk, m4 et optionnellement perl et imake (si j'ai bonne mémoire).
> c'est mon optinion mais je pense que je la partage avec un certain nombre de personnes.
Fedora le fait. Sûr que d'autres distribution le font.
Sous Fedora il y a une tache de fond qui regarde s'il y a des mises à jours. En fonction de la configuration il downloade les paquets voire les installe aussi. Il peut aussi en informer l'utilisateur via syslog, mail ou dbug. S'il n'y a pas d'installation automatique de démandé, l'utilisateur est informé qu'il y a des mises à jour via une applet sur le bureau (communication via dbus). Il clique dessus et lance la mise à jour (optionnellement en choisissant les paquets à mettre à jour).
A ma connaissance, il ne fait pas de reboote. Mais je ne serais pas étonné qu'il y ait une option dans un coin pour le faire.
> Le ext3 a été dégagé pour d'autre raison :
> - perte de donnée
C'est marrant. Un mec fait un test avec ext3 et a des pertes de données. De nombreuse (million?) personnes utilisent ext3 et n'ont pas de pertes de données (ou c'est très rare).
> - corruption totale d'une partiton de 67Go !
cf ci-dessus. Si ext3 était naze, tu crois que Red Hat l'utiliserait ? Red Hat l'utilise pour des données critiques sur des gros serveurs et doivent tourner 24/24 7/7 365/365.
> (alors que je faisais des sync régulier pour l'éviter et aucune freeze lors de ces sync)
Si t'as un système qui freeze, alors tu as d'autres problèmes. Problème hardware ou problèmes qui écrit n'importe où en mémoire. Dans ce cas tous les FS peuvent se planter (avec perte de données et tout).
Il y a eu le cas avec ext3. Le module ntfs (même en ro) écrivant n'importe ou en mémoire et foutait la merde dans les données d'ext3. Il y a eu des cas de FS irrécupérable. NB : ntfs a été corrigé.
Il y a eu aussi ce problème avec le module NVidea.
> - pas de fsck de 3h, tu remonte et paf c'est finis
Avec ext3, ce n'est qu'une question de configuration. Fais "man tune2fs" et "man fstab".
Sans fsck complet, il est impossible pour un FS de détecter un problème hardware (sauf via le retour des fonctions read() et write()). Donc un fsck régulier, même s'il n'est pas exigé par le FS, ne peut pas faire de mal. Loins de là.
> je tourne en 2.6.20tmb
Ben si tu tournes avec des noyaux en développement, plus du "bleeding edge", il ne faut pas s'étonner qu'ext3 (ou n'importe quel fs) plante.
Puisque tu dis toi même que ton journal est trop long, je n'ai pas tout lu.
> On entend souvent dire que le GNU/Linux c'est over-top super trop méga-bien pour le desktop.
Qui dit ça ?
Linus Torvalds qui a dit à mainte fois que rendre Linux compétif dans le desktop est un énorme chalenge ?
Mandriva qui fait du desktop mais ne décolle pas financièrement ?
Red Hat qui fait du pognon mais ne fait pas de Desktop (ou marginalement) ?
Les 0,2 % de poste desktop sous Linux ?
L'absence de l'implication des constructeurs de périphérique "desktop" dans Linux ? (voir le difficulté qu'a Linux pour avoir un Wireless correct).
Dell qui investi dans Linux mais que pour les serveurs ?
Bob Young (créateur de Red Hat) qui a dit que Linux ne serait jamais pour le desktop ? (c'était il y a 7 ans je crois).
> pourquoi sa progression n'est pas aussi importante qu'on pourrait l'espérer.
Qui espérait une progression importante ?
Personne dont l'expertise en reconnue. On s'attend à une montée lente. Ça commence à se mettre en place. Le déploiement de 20 000 postes chez Peugeot est un signe significatif. Je pense que les assurances vont probablement suivre. Mais comme d'habitude, ça va prendre du temps.
> Je suis un peu déçu de n'avoir pas vu ces questions posées plus tôt sur ce genre de forum. C'est comme s'il y avait une sorte de tabou
Absolument pas. Les plus avisés savent que GNU/Linux n'est pas méga-génial pour le desktop. Mais il ne faut pas compter sur les supporter du logiciel libre (dont je fais parti) pour dire que GNU/Linux c'est de la merde.
> pas (ou peu) de développeurs, pas (ou peu) d'applications ; pas d'applications, pas d'utilisateurs ; pas d'utilisateurs, pas de développeurs.
Sauf que GNU/Linux a de plus en plus de développeurs, que le libre a de plus en plus d'adeptes, etc...
Mais ça tu oublies de le mettre dans ton équation.
Tu parles d'un déclin et tu te trompes. Linux grippe et depuis longtemps. Le plus gros fournisseur Linux fait au moins du +30% par an depuis de nombreuse année. Un résultat de progression bien supérieur à MS. Linux prend des parts de marché à MS dans les serveurs. Il avait été prédit que Windows NT et ses successeurs allaient tout bouffer dans le domaine serveur. Ben ce n'est pas le cas. Et ce n'est pas qu'une question de temps. D'un succès garantit de Windows NT (puis 2000, 2003), on est maintenant passé à une position fragile pour Windows dans le domaine des serveurs.
> [blabla autoconf] Sauf que je pense que les mots ne sont pas assez durs pour dire combien ce truc est pourri
Il est unique mais il est pourri...
C'est celà oui...
MS en chie comme un con pour fournir une version 64 bits de son OS, Linux fait ça les doigts dans le nez grace entre autre à autoconf (on a tout en 64 bits sous Linux et depuis longtemps : noyau, libc, base de donnée, bureau GNOME/KDE, etc), mais tu conclus que autoconf est pourri.
On a du GNU/Linux partout. Sur i386, sur AMD64, sur PPC32/64, sur ARM, sur Alpha, etc... alors que autoconf est pourri selon toi.
Pour Windows il n'y a pratiquement rien. Il y a une version Alpha (qui tournait principalement en 32 bits....) et un version Mips. J'ignore si cette dernière variante a vu vraiment le jour.
> Mais là encore, sous Windows et Mac OS on trouve une tétrachié d'outils pour faire du déploiement d'applications convivial (pour le développeur et l'utilisateur).
C'est un blague ?
Faire un paquet rpm ou apt est 10 fois plus simple que de se casser les couilles avec les salopries fournies par MS.
Si rpm ou apt était pourri, tu m'expliques pourquoi on voit tant et tant de paquet rpm ou apt ?
Bon, j'arrète là de lire ton journal. Il y a connerie sur connerie pour les aspects techniques et ça me souale. D'autant que tu parles de développement sous Windows, et moi qui développe aujourd'hui sous Windows (faut bien manger), ben c'est la galère. L'API est immonde (sauf DirectX ceci dit). Apprendre l'API de Windows est un chemin de croix.
C'est depuis que je développe sous Windows que je comprend pourquoi Linux dans une certaine mesure tient tête à Windows. Linux tient tête à Windows car l'OS et son API est beaucoup mieux foutu. L'écart est si énorme, que même s'il y a plus de 100 développeurs Windows pour 1 développeur Linux, ça permet à Linux d'avoir son mot à dire. Si on ne connait pas Windows et Linux, si Windows à 100 fois plus de développeur que Linux (ce qui doit être le cas) on peut se dire que Linux va être balayé.
Si Linux s'impose sur le long terme, ça sera grace à son innovation.
Prends rpm ou apt.Tu les critiques mais quand on y a goûté, ça casse les couilles de passer sous Windows. Et ça les casse gravement.
Pourquoi il n'y a pas l'enfer DLL de Windows sous Linux ? Car Linux a une bonne gestion de version des librairies. Windows n'a presque rien (il y a un truc récent avec les manifest) et c'est pour ça que Windows c'est l'enfer. Pas car Windows a obligation d'avoir une API stable. Linux l'a aussi dans certains domains (glibc, x11, gtk, gnome, kde etc). Red Hat propose des systèmes avec une API binaire et source qui ne bouge pas durant 7 ans et aussi au niveau noyau.
L'enfer DLL de Windows, c'est seulement car Windows sucks. Un exemple, tu sais comment on fait pour passer de Direct3D v8 à v9 ? Ben on change tous les noms des fonctions, des types, etc... Mais même après ça, il n'y a tout simplement pas compatibilité ascendante. C'est ça une politique de compatibilité ?
C'est gentil de parler de la stabilité API de Windows. Mais il faut y regarder à deux fois pour voir qu'il n'y a rien de particulier ou magique.
L'innovation est ce qui va apporter le succès à Linux. Innovation qui permet la modularité. Modularité qui permet entre autre à Linux d'être un succès dans l'embarqué même s'il y a Windows CE. Modularité/innovation qui permet de faire OLPC. OS bien conçu qui permet d'avoir un support pour les nouveaux CPU 64 bits très tôt. OS bien conçu qui permet à Linux d'être le premier à supporter les technologie VT d'Intel et AMD. OS bien conçu qui permet à Linux de faire un carton dans le domaine des cluster (Windows y est maintenant marginal). Modularité/innovation qui permet d'avoir des distributions bien distinctent pour répondre à des besoins spécifiques (voir Gentoo par exemple). Innovation qui permet à Linux d'avoir un système au top pour le réseau (Linux supporte IPV6 bien avant Windows). Innovation qui permet à Linux d'avoir un système au top pour tout ce qui est lié à lvm. Innovation qui a permis GFS, FUSE, etc... Innovation via la disponibilité des sources qui permet à Google d'exister. Sûr que ce que fait Google avec Linux, Google ne pourrait le faire avec Windows.
Il y a plein d'innovations dans Linux qu'on ne retrouve pas dans Windows. Depuis quelques temps le projet stateless suit son court. Il est en phase de développement. C'est une innovation significative qui a moyen terme va séduire beaucoup de décideur/administrateur comme ils ont été séduit par rpm/apt qui permet de gérer ce qui est installé sur les bécanes sans se prendre la tête.
Autre point fort de Linux, et ce car globalement Linux refuse d'être un adèpte de la compatibilité binaire, sa rapidité à déployer les innovations. Linux est passé de linuxthread à NPTL sans grosse difficulté. La gestion fine de librairie a permis de fournir linuxthread et NPTL en parallèle durant la transition.
Linux est passé à UTF. C'est UTF-8 (codage de 1 à 6 octets pour compacter le donnée, mais ça tout UTF-32 qui est dispo) et couvre tout unicode. Windows ne supporte que la version 16 d'unicode.
Mon sentiment, ce n'est qu'un sentiment mais il est fort, est que GNU/Linux va gagner grace à l'innovation et pas car OS n'est pas cher. Un OS gratuit mais avec un TCO élevé ou qui n'offre pas de service attractif, est sans intérêt.
Certe, pour le Desktop Linux sucks aujourd'hui. Il ne sucks pas gravement. L'architecture que propose GNU/Linux est aujourd'hui solide et sans virus (virus : ça mérite un journal complèt quand on parle de Windows, et une ligne quand on parle de Linux). Les fondations de GNU/Linux (via le noyau, udev, hal, dbus, freedesktop pour les standards) sont OK pour un succès dans le desktop. Elle sont plus qu'OK et dépassent même Windows pour tout ce qui est périphériques amovibles (merci Linux 2.6/udev/hal). Mais ce qu'il manque cruellement à Linux, c'est le support des fabricants de périphérique. Fabricants qui misent tout ou presque sur Windows et un peu Mac. Chose compréhensible puisque ces OS trustent le desktop.
Mais dès que Linux prendra une parte significative dans le desktop (5 % suffit), la tendance peut s'inverser rapidement. Et lorsque ça arrivera, ça se remarquera comme c'est arrivé pour Linux dans les serveurs.
> il m'a fallu du temps pour comprendre que c'était la version de l'éditeur de lien dynamique (ld.so) qui avait changé entre temps.
Il n'a changé qu'une fois depuis que j'utilise Linux (depuis 10 ans) !
Mieux, tu peux toujours installer l'ancien éditeur de lien (ce n'est qu'un fichier (ld-1*.so)). J'ai fait tourner des programmes pour Linux 1.0 (0.99 en fait) sur des bécanes avec Linux 2.6. Ça marche comme un charme.
> Apparemment, Gnome à comme chartre ergonomique de limiter les options pour ne pas surcharger l'interface
Je ne te donne pas tord mais il faut voir les choses plus en profondeur. Si l'interface est surchargée mais puissante, c'est (peut-être) tant mieux. On peut voir ça avec certain logiciel (type outils de développement).
Plus d'option, c'est plus de choix plus de posibilité. Gnome n'est pas contre le choix et fournir plus de possibilité.
Mais quel choix et à quel coût ?
Exemple :
J'ai un logiciel de gravage (c'est un exemple fictif). Lorsque je le lance il me laisse choisir le graveur à utiliser. C'est bien. Mais s'il y a une galette que dans un graveur et rien dans l'autre graveur, c'est con. Il est claire que je ne vais pas graver avec le lecteur qui n'a pas de galette. On a une option inutile. Inutile si on a un moyen de detecter la présence de galette. Au-lieu d'imposer l'option, le mieux est d'avoir un moyen pour detecter la présence de galette. S'il y a deux galettes on propose à l'utilisateur de choisir, s'il n'y a qu'une galette on ne lui propose rien, et s'il n'y a pas de galette, on lui demande de mettre une galette (il choisi le graveur qu'il veut). Cette description est naïve si sur le bureau il y a des icones qui représente les graveurs.
Le logiciel de gravage me permet de choisir la taille du buffer à utiliser. C'est bien car la gravage peut planter si le buffer vient à se vider. Mais en réfléchissant un peu, c'est con. On a une fonction pour graver mais elle peut ne pas marcher. Donc cette fonction est buggée (du moins vu de l'utilisateur). Il faut corriger cette fonction pour qu'elle marche tout le temps et ainsi on fout la paix à l'utilisateur.
On peut multiplier les exemples. Beaucoup d'options sont souvent là pour corriger des déficiences. Ce que ne veut pas Gnome, et plus que de ne pas surcharger l'interface utilisateur, est d'avoir une interface pour pallier à des déficiences du système sous-jacent. Donc au-lieu d'ajouter une option, Gnome bosse sur les "fondations" du bureau. C'est-à-dire des parties non visible, sur le système sous-jacent. Un excellent exemple est HAL. L'utilisateur ne voit pas HAL mais HAL enrichi énormément le système sous-jacent ce qui permet une intéraction "intelligente" entre le bureau et le système sous-jacent. Ce qui permet de virer des options. Pour virer quelques options, il a fallu développer udev/dbus/HAL. Un énorme travail ! Et pas pour limiter l'utilisateur, pas pour lui proposer moins de possibilité !
Un projet comme Gnome n'est pas qu'une surcouche graphique du système d'exploitation. Ses ramifications s'étalent un peu partout dans le système et on ne peut que se féliciter de l'implication de Linus.
D'où des projets comme freedesktop. Fournir un système sous-jacent adapté à un bureau.
Certe Gnome peut être irritant. Il peut être rapide d'avoir quelque chose de fonctionnel en ajoutant une option. Gnome le refuse. C'est irritant mais ça a aussi une vertue. Ça pousse les développeurs à corriger les défauts là où ils sont.
Ce qui est important, c'est que la webcam marche, que le wifi marche, etc... Pas que ça marche en bidouillant des fichiers et en triturant 40 options au petit bonheur la chance, mais que ça marche lorsque c'est monsieur tout le monde qui le met en oeuvre. Ceci est valable pour Windows, KDE, Gnome, Mac OS, etc...
Ceci est de très très loins le plus important aux yeux d'un utilisateur. C'est ça l'objectif "ultime" de Gnome. Que ça marche ! Pas que ça marche en ajoutant une rustine (une option), mais que ça marche "out of the box". Et c'est ça que les utilisateurs veulent ! Qu'ils soient geek ou que ce soit ma grand-mère. Le problème de Gnome ou de n'importe quel bureau libre (KDE, XFCE, etc) n'est pas le manque de l'option bidule ou que le double clique sur prout fait crak ou bling. Il suffit de voir le succès de Windows pour se convaincre que ce n'est pas en ajoutant l'option bidule ou le double clique qui fait bling que GNU/Linux va attirer des utilisateur de Windows de façon massive. Ce dont ne se rend pas compte le geek assoifé d'option d'aujourd'hui, est qu'il y a des tonnes et des tonnes d'options qui sont passé à la poubelle avec l'évolution de GNU/Linux et pour le bien de GNU/Linux.
Les options virées en corrigeant le système sous-jacent porte peu à discussion en général. Du moins une fois que le système sous-jacent est corrigé.
Mais il y a un autre type d'option et qui est d'ordre "culturel". Un Windowsien n'ira jamais demander de pouvoir programmer des options en fonction du bouton de la sourie utilisée. Ça ne lui manque pas, il n'y pense pas. C'est accessoire. OK, ça peut être important pour tel ou tel utilisateur (voir Linus par exemple :-)). OK, ça peut être plus que culturel et un vrai atout pour la productivité de l'utilisateur. OK, les développeurs de Gnome peuvent y répondre et ils pourront se dire qu'ils élargissent le nombre d'utilisateur potentiel tout en augmentant leur productivité.
Mais ça a un effet de bord, parmis d'autres, non négligable. Ça augmente le ticket d'entré pour utiliser le bureau. S'il y a plein d'options, pleins de concept à la vue de l'utilisateur, ce dernier est obligé (en tout cas il se sent obligé) d'assimiler tous ces concepts/options. Cette profusion d'options/concepts/fonctionnalités aussi utile et justifiée par telle ou telle catégorie d'utilisateur, ajoute de la confusion. Au-lieu d'avoir un bureau convivial, on a un "truc" intimidant.
D'un côté l'ajout d'option/fonctionnalité semble élargir le nombre d'utilisateur potentiel, et d'un autre sa diminue le nombre d'utilisateur potentiel. Il y a un compromis entre fonctionnalité et simplicité/convivialité. On peut trouver que le curseur est un peu trop à droite, un peu trop à gauche, que KDE l'a placé pile où il faut et que Gnome est à côté de la plaque, etc...
Sans étude aprofondie et lourde à mettre en oeuvre, on est dans le subjectif pour savoir où il faut placer le curseur. Mais avant de juger, il faut déjà voir les intentions. Et l'intention de Gnome n'est pas d'être le bureau préféré des développeurs noyau.
Par contre, on peut affirmer qu'un bureau adapté à tout le monde est impossible à réaliser. C'est pour ça que la réaction de Linus, et sauf tout le respect que je lui voue, m'énerve passablement. Dire que tous les utilisateurs doivent utiliser KDE est une connerie. Dire que tous les utilisateurs doivent utiliser Gnome l'est aussi. Dire que Gnome prend ses utilisateurs pour des cons est une connerie. C'est respecter les utilisateurs que de proposer quelques choses de simple/accessible et non les prendre pour des cons.
La BMW de Linus doit avoir un système anti-dérapage préréglé qui ne lui permet pas de jouer avec les 150 paramètres utilisés en interne par ce système, les amortisseur sont peut-être pilotés, une clim qui répartit la température de sortie des buses vers la tête et les pieds (alors qu'il pourrait y avoir un potentiomètre pour régler ça), il n'y a que deux vitesses pour les essuis-glaces (alors qu'on pourrait avoir un potentiomètres), etc... Naïvement on peut dire que tout ceci limite l'utilisateur. L'utilisateur avertit dira que le réglage anti-dérapage ne lui convient pas et qu'il est dommage qu'il ne puisse bidouiller avec ses 150 paramètres, qu'il n'y a pas de réglage d'amortisseur qui correspond aux pavés de son village, que la clim lui chauffe trop les pieds et qu'il est dommage qu'il ne puisse pas bidouiller la puce qui régule la clim, que les vitesses préréglées pour les essuis-glaces ne sont pas adaptées au crachin de sa région et qu'il est dommage que ne puisse pas la réglée, etc... Mais ce n'est pas prendre l'utilisateur pour un con. Sinon BMW a pris Linus pour un con et le tout en lui piquant une somme bien rondelette (beaucoup plus que Gnome:-)).
Mais ce que fait BMW (et beaucoup) es-ce limiter l'utilisateur ? Ça dépend de l'utilisateur. Si l'utilisateur est un amateur/expert en voiture (type Alain Prost) alors oui. Si l'utilisateur est un consommateur/utilisateur de voiture moyen (type Linus) alors non. Si pour conduire ma voiture je dois lire un manuel de 500 pages et passer 15 minutes à configurer le bousin avant de démarrer, ben je suis très limité dans l'utilisateur de ma voiture. Et le vendeur de la voiture m'a pris pour con.
Je ne vois pas pourquoi tu dis ça. Linus c'est trompé de mailing, ce n'est pas un drame. Il ne connait pas les arcades de Gnome et on ne va pas lui reprocher.
Il fournit des patchs, qu'il en soit bénit :-)
Les développeurs Gnome ne vont surtout pas s'en plaindre. D'autant que Linus est un "géni" pour ce qui est coder.
Une bonne âme a poussé les patchs de Linus dans bugzilla : http://bugzilla.gnome.org/show_bug.cgi?id=408898
NB : Linus ne veut pas créer un compte bugzilla (ça l'emmerde de créer un nouveau compte et globalement il n'aime pas bugzilla).
Des patchs ont été validés, d'autres sont en cours de discussion.
Linus n'aime pas l'"esprit" Gnome. Il n'a pas sa langue dans sa poche (tant mieux) et son style de communication est disons brutal, mais les arguments souvant percutant.
Cependant, il devrait avoir en tête qu'un bureau qui ne lui satisfait pas, n'est pas un bureau qui ne satisfait personne, et que ce qui fait son bonheur, ne fait pas le bonheur de tout le monde.
> Je crois que ce serait mieux de leur filer des pcs sans troyans intégré, c'est si choquant que ça?
Fais le, ça ne me choquera pas du tout. Et je suis convaincu que la grande majorité des pays pauvres te laisseront faire.
Surtout ne propose pas de support, sinon tu vas exploser ton budget. Le moindre pépin va coûter au moins 5 000 ¤ (et oui, ils n'ont pas de SSII, d'Internet, de courrant, etc). Et comme en plus tu fais tout pour ne pas les éviter...
En Europe on peut tolérer d'augmenter le prix d'un PC de 50 voire 100 ¤ pour le support. Mais pour OLPC, ce n'est pas tolérable. La bécane doit être blindée de chez blindée.
Fais cadeau de PC sans restriction. Ton cadeau finira par être un cadeau empoisonné ou au mieu un déchet.
> Imagine tu es un gosse de pays émergent et qu'on t'offre une machine rien que pour toi
Ben fais le. Offres (réellement) des OLPC. Je t'y encourage vivement. Ce n'est pas aujourd'hui possible, mais OLPC le prévoit à moyen terme. Ainsi tu pourras acheter 1 ou 2 OLPC et les envoyer à un pays pauvre. Aujourd'hui OLPC est concentré sur les gros clients.
Les OLPC ne sont pas offerts, ils restent la propriété de l'acheteur (gouvernement/ONG/etc). Comme quand ton entreprise achete un PC et installe Linux. C'est la propriétait de l'entreprise et le fait que Linux soit libre, n'implique pas que l'entreprise est obligé de fournir le mot de passe. On peut le regretter que les OLPC ne soit pas offert aux utilisateurs finaux, mais c'est mieux que rien, c'est mieux que des PC conçu à l'origine pour les pays au climat tempéré où il n'y a pas un grain de sable dans l'air.
Imaginons que tu as donnée 1000 OLPC dans une région reculée, à l'accès difficile, sans courrant, sans téléphone, etc...
1 OLPC sur 10 tombe en panne car tel ou tel gus a installé un noyau perso, 1 OLPC sur 10 est volé "avec succès", etc...
Tu fais comment pour réparer les dégâts ? Tu livres les OLPC avec un numéro de téléphone vers un hotline ? Chaque coup de téléphone va couter le prix d'un OLPC...
Tu installes gratuitement Internet dans cette région reculée ? Excellente idée.
> aucune personne tierce ne pourra controler sa machine aussi facilement à distance, ça c'est un fait.
Comment ça contrôler sa machine ?
Pour quoi faire ?
Probablement pour mettre à jour, corriger un petit problème, inhiber la bécane si elle a été volée, etc...
Tu crois que le gouvernement où les ONG n'ont que ça à foutre : surveiller chaque OLPC ?
Et comment est faite la prise de contrôle ?
Sans l'accord de l'utilisateur ?
S'il y a des prises de contrôle sans l'accord de l'utilisateur, elles permettent quoi ?
De lire /home ou seulement de mettre à jour des programmes ?
De tout manière, entre pas de OLPC ou un OLPC contrôlé par l'état, je préfère un OLPC.
Je répète, si tu veux fournir des OLPC contrôlé par personne, n'hésite surtout pas.
> Et si on veux que le bidouillage ne pose pas de problème, on fait un beau gros bouton reset
Pour que ça marche, il faut que le système d'origine soit en ROM et que toutes modifications arrivent en RAM. C'est bien, mais ça coûte très cher, d'autant que le système d'origine fera dans les 300 Mo voire beaucoup plus (j'ignore combien exactement). Les OLPC ne sont pas destinés a des utilisateurs d'Internet à qui on fournit un système minimum et qui ajoute les programmes qu'ils veulent via le web. OLPC sera livré complet, voire bourré d'information au maximum. Je ne sais pas où ça en est, mais il était prévu d'avoir wikipedia dans OLPC. Pas un navigateur qui se connecte au site wikipedia (la majorité des OLPC n'auront pas de connexion internet), mais wikipedia (une partie du moins) sur l'ordinateur.
Bref, ta solution est très cher. M'enfin, je te félicite d'avoir proposer quelque chose et qu'on puisse en débattre. Vas savoir, ton idée fera peut-être son chemin et il y aura peut-être une version de OLPC, plus cher, mais qui offre la possibilité que tu demande. On pourrait avoir un "double boot". Boot sur la version administrée/contrôlé par l'état et qui doit être rock solide, boot sur une version disponible aux bidouillages les plus fous sans que ça affecte la version "gouvernementale".
Ce qu'il faut comprendre, c'est que les bécane OLPC sont "adminitrées" par le gouvernement/ONG. Si tu veux acheter des OLPC et fournir les clées pour que l'utilisateur puisse tout foutre en l'aire, n'hésites surtout pas.
Je suis convaincu que les gouvernement/ONG commanderons à terme quelques OLPC sans clée, ou avec une clée qu'ils pourront communiquer, pour les hackers en herbe, etc...
T'as un FAI, tu y dépose des informations importantes, tu utilises leur serveur mail, etc... Pourtant tu n'as pas les sources, et le gouvernement peu fouiller tes communications (inutile d'aller dans une dictature pour voir ça, c'est possible en France, il y a les décrets nécessaires).
OLPC est "mis à disposition" comme une entreprise met à disposition un PC pour ses employés, comme un FAI met à disposition un serveur mail, etc...
Si tu n'as pas confiance en ceux qui mettent à disposition OLPC (et pourquoi pas), ben n'utilises pas et achetes toi un OLPC avec les clées ou trouves une personne qui te donne un OLPC avec les clées (il semble qu'ici plein de gens sont disposés à mettre l'argent sur la table pour ça... (rire)).
Si un pays n'autorise que des OLPC sous leur contrôle, là il y a un sérieux problème.
J'aimerai bien être dans un monde idéal, où on peut fournir des OLPC sans protection pour que les utilisateurs puissent se défoncer, etc...
Mais on n'est pas dans un monde idéal. Les populations des pays pauvres le savent très bien.
> ça n'est apparemment pas libre pour l'utilisateur (puisqu'il n'en est pas propriétaire).
Si tu veux acheter des OLPC et les données avec la clée "et tout", n'hésite pas.
Tout le monde t'applaudira des deux mains. Moi compris.
Je suis sûr que la majorité des pays où est destiné OLPC verront ça d'un très bon oeil même si ça met en péril leur "dictature".
Si un pays refuse ton offre, n'hésite pas à nous en informer.
J'ai dit : "- Tu me fais penser ..."
J'aurai du dire : "- Ton commentaire ..."
> Eh, calme toi un peu l'ami, l'extrémiste ici ce serait plutôt toi ! (en refusant la moindre critique).
C'est facile.
On a un fabuleux projet sans équivalent, et il n'y a que des gus qui critiquent, qui font des fantasmes sur un complot planétaire, etc...
> Ce n'est pas parce que ça a l'air novateur qu'il faut foncer tête baissée sans analyser les possibles dommages collatéraux
Et quel dommages collatéraux ? T'as évaluer les conséquences s'il n'y avait pas OLPC ? Quel serait les dommages collatéraux ?
Ben on laisse la "fracture numérique" et on tourne ses yeux ailleurs... Ah non, on envoie un peu de bouffe, c'est tout ce qu'il mérite.
> et ce n'est pas parce que c'est du linux sous le capot que les utilisateurs seront libérés, eux !
Les libérer de quoi ? De l'emprise de Microsoft ?
Ils n'ont pas Windows ou Mac ou Linux, ni rien.
C'est quoi ton délire ?
Je vais être claire, si MS fait la même chose que OLPC (même fonctionnalité, même possibilité pour les utilisateurs, même coût) mais que le tout en propriétaire, ben j'applaudis des deux mains.
L'enjeux "libérer" est accessoire dans OLPC par rapport aux vrais enjeux.
> mais j'ai avancé des arguments qui effectivement montrent une certaine réserve.
Et mieux que OLPC il y a quoi ? Tu proposes quoi à part des belles intentions ?
C'est comme pour la constitution européen, les donneurs de leçon, ceux qui lavent plus blanc que tout le monde, les biens penseurs qui se prétendent hors de la pensée unique, ont poussé le non car ils avaient mieux ... dans leur fantasme, car ils avaient "des réserves". Au final on a rien.
Prenons les choses positives qui se présentent et avançons au-lieu de tortiller du cul et faire du sur place dans notre merde.
> Mais je ne suis pas parfaitement convaincu par le rapport bénéfice/coût de l'opération par rapport à des méthodes + classiques (profs + cahiers).
La méthode classique, il l'applique aujourd'hui. Et ta méthode classique c'est quoi ? Les laisser là où ils sont ? Que surtout pas ils évoluent ?
> Je ne sais pas si ça sonne "extrême gauche" pour toi, mais je trouve qu'ils manquent déjà de bcp de choses et qu'on ne peut pas se permettre de dilapider des ressources dans un "gadget" !
Dilapider des ressources ?
C'est du délire. On met des ressources pour les gens qui en n'ont le plus besoin et tu parles de "dilapider des ressources"...
Effectivement si dans ton esprit il faut les maintenir dans notre dépendance en n'accordant que de la bouffe au pays pauvres histoire de les maintenir en vit et avoir bonne conscience, effectivement on "dilapide des ressources" par rapport à cet objectif.
Pour toi, c'est un "gadget". Pour moi, ici et maintenant, c'est un "gadget". Pour ceux qui n'ont pas de calculatrice, qui n'ont pas de courrant, qui n'ont rien, ce n'est pas un "gadget".
> vu que ça aura forcément un coût
Maintenir les pays pauvre dans leur pauvreté, ne pas leur donner les moyens d'augmenter le niveau de leur connaissant, ne pas leur donner d'outils, ne pas les inciter à utiliser l'informatique en proposant un produit adapté à leur environnement, ça a un coût. Et ce coût ne s'exprime pas en monnaie sonnante et trébuchante.
Ne t'inquiète pas, OLPC ne va pas augmenter tes impôts. T'auras toujours les moyens d'avoir 2 TV chez toi et de nourrir ton chat avec des boites "Gourmet" 5 étoiles.
Critiquer le "produit" OLPC est compréhensible. L'écran est peut-être trop petit, la manivelle trop fragile, l'autonomie faible, etc... Les développeurs de OLPC le font tous les jours, et tous les jours ils essaient d'améliorer le produit OLPC au-lieu de rester le cul sur une chaise en attendant qu'un solution parfaite, sans "effets collatéraux", tombe du ciel.
Mais on fait quoi en attendant ? Je sais, on envoie de la bouffe. Ça nous coûte pas cher, ces pays restent sous notre dépendance et ne viendront jamais nous concurrencer. Beau programme...
Tu veux les libérer du logiciel propriétaires (foutaise), ils faut les libérer des pays riches. Et ça passe avant tout par l'éducation.
[^] # Re: ESR est un has been
Posté par IsNotGood . En réponse au journal ESR passe sous ubuntu. Évalué à 10.
Ça c'est le troll de base.
Deb sucks : http://linuxrevolution.blogspot.com/2006/08/ubuntu-update-br(...)
Bon voilà, la balle est au centre.
ESR gueule car il a fait un "rpm -e --nodeps lib_essentielle_pour_rpm". Il a forcément fait un "--nodeps" car c'est une librairie qui est utilisé et les dépendances de librairie sont calculée automatiquement par rpm. Après rpm ne marchait plus. Et donc après il gueule car il n'y a pas de version static de rpm dans Fedora. Il a fait une connerie, il assume. Le jour où il fait "rm -f /bin/rpm_static" il va gueuler car il n'y a pas /bin/rpm_static_au_secours pour les con qui virent /bin/rpm_static.
Et ESR est de mauvaise fois car il sait comment récupérer ce type de connerie. Il suffit de booter avec le CD-ROM ou d'utiliser une installation parallèle.
Le problème, s'il y en un, ce n'est pas rpm. C'est le contrôle des dépôts. Ça n'a rien à voir avec rpm ou deb.
Autre chose. Beaucoup qui utilisent Fedora ajoutent plein de dépôt qui sont, et c'est très souvent indiqué, incompatibles avec Fedora Extras. Mais en même temps ils ont Fedora Extras. Au final ça ne peut que exploser. Et passer à deb ne change rien à ce problème. Sans compter que deb ne supporte pas multilib, ne supporte pas SeLinux, etc...
L'autre problème classique, c'est un mirroir qui n'est pas à jour. Par exemple Fedora Extras est mise à jour (passe une libtoto-1.2 à libtoto-1.4) et dans l'heure livna est mis à jour pour utiliser libtoto-1.4. Manque de change lorsque l'utilisateur fait "yum update" alors que son mirroir Fedora Extras n'est pas à jours. Donc yum dit qu'il manque libtoto-1.4 pour faire la mise à jour (et il a raison). Dans ce cas, il faut faire sont "yum update" le lendemain et c'est tout. L'échec du "yum update" précédent est sans conséquence.
Ce problème on l'a aussi avec deb.
Un fois qu'on enlève ces problèmes classiques qui n'ont rien à voir avec rpm et où deb n'est en rien une solution, il n'y a pas de problème avec une Fedora stable. Ou alors c'est exceptionnel (genre une fois tous les 3 mois) et sans conséquence (puisque la mise à jour est refusée).
Pour F7, il y aura un contrôle systèmatique (via un programme qui contrôle les dépendances d'un dépôt). Par exemple un paquet ne pourra être mise en "update" s'il casse des dépendances. Ceci n'a rien à voir avec rpm.
NB : F7 aura les dépendances de contrôlé pour "feu" Fedora Core et Fedora Extras. F7 ne va pas contrôler les dépendances de Freshrpms ou Livna par exemple.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
>
> Ben faut mieux regarder, ils ont tout un tas de failles de securite eux aussi.
Des trous de sécurité qui ont coûté des milliards comme Windows ?
Me fais pas rire. Et rapporte aussi au nombre de poste (à la popularité), Mac n'est pas la catastrophe Windows.
> Au hasard tu peux donner ton propre systeme d'authentification(qui permet de faire authentification biometrique, smart card, ... ou n'importe quoi auquel tu pourrais penser)
Oui, ça existe sous Linux. Je n'en suis pas fan. RHEL le fournit.
Alors que je te demande un add-on équivalent de SeLinux, tu réponds répond par ce qui pourrait être un module PAM.
> IE7 par contre, il ne peut acceder a rien a part le repertoire cache, et un autre repertoire je crois.
Ben tant mieux si MS se met enfin à faire des trucs sûrs.
> > Non seulement il te le donne, mais tu peux aussi le changer. Que du bonheur...
>
> Tu m'expliqueras comment faire, je suis interesse
Menu : Tools | Internet Options...
Onglet : Sécurité.
> Donc tout ce qui n'est pas _necessaire_ est une arnaque ? Ta montre est une arnaque? Non c'est bien ce que je pensais.
Tu achètes un antivirus pour faire joli ? Pour écouter de la musique ?
Pourquoi pas, si c'est joli et que la musique est bonne.
Pourquoi tu achetes un antivirus au fait ?
Car c'est utile/nécessaire ou pour faire joli ?
> Un anti-virus tu l'achetes car tu n'es pas capable de savoir si il est sur de lancer cet executable inconnu qu'un site web te propose.
La bonne excuse...
Les virus qui ont coûté des milliards à l'industrie et ont foutu la panique jusqu'à passer au 20 h de tf1 et en boucle sur france info, c'est car les gens downloade explicitement un programme et le lance explicitement.
Mais oui...
> Vu que Windows est utilise par des gens ne connaissant rien a l'informatique et susceptible de lancer tout et n'importe quoi oui.
L'utilisateur de Windows a besoin d'un BigBrother. L'utilisateur de Windows est un con qui lance tout et n'importe quoi.
> Maintenant je serais ravi que tu me prouves, car tu ne l'as toujours pas fait, la difference architecturale entre Windows et Linux qui fait qu'un anti-virus est _necessaire_ sur l'un et pas l'autre.
En simpliant tout à l'extrème comme tu le fais, alors oui "la difference architecturale entre Windows et Linux" est nulle.
Mais à part la popularité de Windows, tu n'as pas avancé l'ombre d'un embroyon d'explication sur le FAIT que Windows a coûté des milliards en virus et attaques en tout genre, ni que Windows a besoin d'un antivirus (à part dire que les utilisateurs de Windows sont des cons contrairement aux utilisateurs de Linux (merci pour ces derniers)).
Quand Linux sera populaire (20 % des postes) et qu'il aura pas d'antivirus ni de problèmes qui coûtent des milliards, je serais très curieux de voir ton explication. Je sens qu'il va falloir se contenter d'un "Windows n'a eu de chance".
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
Les chiffres de Red Hat sont des chiffres comptables. De plus Red Hat étant en bourse ils sont vérifiables. Là tu dis que Red Hat magouille et tu pousses le bouchon un peu loin si tu n'as aucune preuve. Et si t'en as, lance des poursuites contre Red Hat. Tu es sûr de gagner et tu auras la bénédictions des actionnaires de Red Hat.
> IDC un peu moins.
Je n'ai pas remis en cause l'honnêteté d'IDC dans cette étude.
> Quand a OpenOffice 64 bit, si je vais sur http://download.openoffice.org/680/index.html je ne le vois pas
http://fr2.rpmfind.net/linux/fedora/core/6/x86_64/os/Fedora/(...)
Cherches openoffice, tu le trouveras en 64 bits. Ce n'est qu'un exemple.
Ceci dit, c'est récent. Mais Openoffice est aussi dispo sur Sparc depuis longtemps.
> a) Tout n'est pas dispo en 64bit sur Linux, loin de la
Ouais, il manque flash.
Tout n'est pas dispo en 64 bit sur Linux. Seulement 99,9 %.
> b) Tu me montres la difference des APIs entre 32bit et 64bit sur Windows ? Je t'aides, t'auras du mal.
Ben si tout nickel (au moins autant que Linux), MS-Office en 64 bits ne coûte rien à faire et devrait déjà être là !
Alors pourquoi il n'y a pas de MS-Office en 64 bits alors que depuis Windows NT il y a une version de Windows en 64 bits ?
Si Fedora/OOo (idem pour RHEL le produit commercial avec support et tout) le fait, j'ai énormément de difficulté à comprendre pourquoi Windows ne le fait pas si selon toi il n'y a aucune difficulté. Et notes bien que les moyens de Microsoft n'ont rien à voir avec les moyens ridicules de Red Hat à côté.
> Quand a Office, ben pour la meme raison qu'OpenOffice faut croire...
T'es un peu girouette...
> Ben moi je vais voir http://www.redhat.com/about/presscenter/2005/press_rhel4.htm(...) et je vois qu'ils supportent x86, Itanium, AMD64 et Power.
> Voila, ca fait UN de plus que Windows, c'est a dire aucune difference a peu pres.
Sauf qu'il y a tout dedans. Et pour PowerPPC, c'est 64 bits.
De plus, je n'ai pas souvenir que Windows a une version AMD64 ! J'ai seulement entendu parlé de versions béta et qu'il y a une version AMD64 pour Vista. C'est donc très récent. Quand on connait les moyens de Windows, si tu affirmes qu'il n'y a pas de problème pour MS de fournir du 64 bits, on a un sérieux problème de logique dans ce que tu dis.
Pour info, AMD64 (en vrai 64 bits) est dispo depuis RHEL 3 (avec support et tout et plein de programme). Et pour une version de Linux en 64 bits (avec 99,9% des logiciels) il faut remonter à la nuit des temps.
M'enfin, continu d'affirmer que windows est aussi portable que Linux.
> Windows supporte UTF-16 depuis un moment deja(depuis XP en tout cas), ca fait 6 ans...
Ben je n'ai vu que ucs-2.
> ca fait 6 ans...
Ce qui est du pipo. Windows est passé à ucs-2 avec Windows NT (ou 2000?). Et je dis bien ucs-2 (2^16 caractères) et non utf-8 (2^32 caractères). Windows 2000 utilise ucs-2 (j'en mettrais ma main au feu) et XP n'est qu'une évolution de Windows 2000.
> Par contre plein de boites prennent leur ancien code 16bit et veulent le recompiler en 32bit, et la ca rend les choses bcp plus simples vu qu'ils n'auront quasiment pas a changer leur code.
+1 pour toi. Même si je trouve que c'est de la connerie à moyen/long terme.
> Il n'y a pas de PID pour les threads sous Windows, il y a un thread ID
Oui. Désolé d'avoir dit PID.
> Linux a un Process ID pour des threads, alors que ce sont des threads, pas des process, tu m'expliqueras la logique.
Linux a :
- Process ID pour les thread : c'est le même pour tous les thread d'un processus (normal, tous thread appartient à un processus). Le thread n'a pas cette information directement attaché à lui.
- Thread ID pour chaque thread : Le type n'est pas pid_t mais pthread_t
J'espère que tu vois maintenant la logique évidente.
C'est comme ça pour LinuxThread et NPTL.
Par contre au niveau noyau (chose dont n'a pas à se préoccuper le développeur), les numéros de processus (pid_t) et de thread (pthread_t) sont partagés. Le premier thread d'un processus a pthread_t = pid_t. Pour les autres pthread_t != pid_t (quelque soit le thread et le processus). Mais ça le développeur s'en fout. Si un jour Linux change ça, il n'y aura pas de problème de portabilité (sauf pour les applis codé avec les pieds).
> Pour les APIs multithread, de nouveau, c'est parece que tu ne comprends rien a l'architecture de Windows.
Tu serais gentil d'arrêter de me prendre pour un con.
> Tu fais comment pour attendre sur un event, un timer, la fin d'un thread, ... sous Linux ? Ah oui, des APIs differents, sous Windows, tous ces elements sont des objets, et tu utilises WaitForSingleObject.
+0,1 pour toi. Mais Windows a encore mieux et ça on ne le trouve pas sous Linux :-)
C'est WaitForMultiObject et notamment avec l'option "auto-reset". Avec les mutex c'est intéressant, d'autant plus que c'est atomic. On peut le simuler sous Linux mais ce n'est pas trivial.
> Sous Windows, personne n'utilises le modele "plusieurs processus"
Ce qui est de la connerie. Le modèle "plusieurs processus" a ses avantages et idem pour le multi-threading.
Le gros problème du multi-threading est que le plantage d'un thread fait planter pour le processus. Et c'est la même chose sous Windows.
Alors que Windows fasse un gros processus. Les autres programmes (stockés dans des dll) seront dans des threads. C'est techniquement tout à fait réalisable. Mais dès qu'un truc plante, tout plante. Et il me semble bien que Windows fournit un truc style "job control" pour "mimer" Unix. Les "jobs" sont des processus et non des thread.
Donc ne dit pas que "Sous Windows, personne n'utilises le modele "plusieurs processus"" car c'est absolument faux.
> sous Unix c'est frequent car jusqu'a recemment le support des threads etait a chier
Rires. Tous les Unix commerciaux ont du multi-thread depuis longtemps. Il n'y a que Linux qui a mis du temps car Linux a débuté en 91 (il était embryonnaire). La version 2.0 de Linux avait le multi-thread. Linux 2.0 est sorti quasiment en même temps que Windows 95/NT (en fait Linux l'avait pour la version 1.2.13 mais pas pour 1.2.0). Donc Windows n'a pas le multi-threading depuis plus longtemps que Linux et assurément pas avant les Unix commerciaux. Le seul problème de Linux est que durant assez longtemps il n'avait pas de thread au niveau noyau. C'est-à-dire que ça ne permettait pas de tirer profit des systèmes multi-cpu. Mais sur la bécane de messieur tout le monde on a rarement du multi-cpu (et même sur la majorité des serveurs).
Notons que les gains de performance du multi-thread sur le multi-processus n'est pas énorme (et souvent nul). D'autant plus que créer un processus sous Linux n'est pas cher (fork() ou clone()).
On a vu plusieurs projet forker un projet pour le passer en multi-thread sans qu'il y ait de gain.
> le support des threads etait a chier
C'est-à-dire ? Depuis Linux 2.0 le multi-thread est Posix. Il n'était pas parfaitement Posix mais à 98 % Posix. NTPL l'a rendu 100% Posix (ou 99,9 %). C'est ce qui a permis aux applications Linux de passer rapidement de LinuxThread à NPTL.
Exemple : Il y avait LinuxThead et NPTL dans RHEL 3. Il n'y a que NPTL dans RHEL 4. Pourtant fournir LinuxThread en parallèle n'est pas un problème. Mais porter les applications vers NPTL n'est pas un problème non plus.
Donc si tu dis que le multithread était à chier, il doit l'être encore aujourd'hui selon toi.
L'intérêt de NPTL n'était pas de passer d'un multi-thread à chié à un truc formidable. Mais d'avoir le multi-threading en mode noyau et être plus conforme Posix. C'est tout, bien que la tâche n'a pas été évidente.
NPTL a des avantages significatif dans le cas où on a plus de 50 ou 100 thread. Ça ne conserne pas la majorité des applications, c'est le moins qu'on puisse dire.
> resultat, tout le monde utilise les CRITICAL_SECTION
Je ne vois pas le rapport. Je n'ai pas dit que CRITICAL_SECTION était mauvais. Je parlais de l'API. Relis.
> Un block memoire ? Tu fais ca comment pour avoir un HANDLE sur un block memoire ?
CreateFileMapping() par exemple.
Mais je suis mauvaise langue.
Je me suis trompé.
Il y a (si j'ai bonne mémoire) LocalAlloc qui retourne un HLOCAL et j'ai conclus rapidement qu'un GlobalAlloc retourne un HANDLE alors qu'il retourne un HGLOBAL (si j'ai bonne mémoire).
Retourner un (void *) comme tout le monde ça aurait été trop simple...
> tu peux attendre sur tous ces objets avec le meme API. Bien plus simple que les 32 APIs differents pour faire la meme chose sous Linux.
C'est une façon de voir la chose. Mais il n'y a aucun contrôle de type. Le seul intérêt des HANDLE est le WaitFor*Object(). C'est tout.
De plus WaitForSimgleObject ne marche pas pour tout. Il marche que pour attendre la fin d'un timer, la fin d'un thread, etc. Mais un WaitForSem() qui attend qu'un sémaphore passe à 10 ça n'existe pas.
Vu la contrepartie, je trouve ça sans intérêt. Par contre WaitForMultiObject (ou WaitForMultipleObject ?) c'est cool.
Sous Linux pour attendre la fin d'un thread on fait pthread_join(pthread_t, void **). Ce n'est pas la mer à boire, c'est lisible.
> Oh si on le sait, c'est meme documente, comme tous les autres types : http://msdn2.microsoft.com/en-gb/library/aa383751.aspx
Donc on a des api qui exige spécifiquement du uint32...
Sous Linux on n'a pas ça. On a pid_t qui on une taille qui colle au hardware ou au besoin de la fonction. Mais on ne dit pas qu'un pid_t doit être un uint32. Un jour c'est un int16, un autre c'est un int32, on s'en fout. Il y a toujours des exceptions. Mais tant qu'elles sont rares, ça se gère. Sous Windows l'exception est la règle.
> mais visiblement tu ne lis pas la doc, dans ce cas pas etonnant que tu n'y comprennes rien.
J'en ai lu beaucoup sur Windows ce dernier mois.
> Plutot que dire que c'est pour des conneries, et si tu donnais des exemples ou c'est inutile ?
WTypes.h
Le wchar_t je vois l'intérêt. Le WCHAR pourquoi pas. Mais les LPCWSTR, etc c'est stupide et ça n'améliore pas la lecture du code (il faut connaitre une tripoté de typedef).
Puis selon http://msdn2.microsoft.com/en-gb/library/aa383751.aspx WCHAR c'est :
Donc Windows ne support que ucs-2. Merci d'en faire la démonstration.
Tu me traites de con qui ne sait pas lire la doc. Je bosse sur Windows en tant que développeur depuis 1 mois seulement. Toi ça fait depuis des années et tu ne sais toujours pas que Windows ne supporte que ucs-2 et pas UTF-8. UTF-8 est une façon de coder usc-4 (unicode) et a 2^32 valeurs. Ça ne rentre pas dans du 16 bits. wchar_t sous Linux est dans son implémentation actuelle du 32 bits. wchar_t n'est pas défini comme étant un int32, mais comme étant un wide caractère. Qu'il occupe 8, 16, 24 ou 32 bits, n'est pas une propriété que le développeur doit utiliser ni savoir (sauf pour débuggeur).
Avec la définition qu'a Windows de wchar_t, ça ne va pas être facile de passer à usc-4...
> Tout comme sous Windows, mais ton probleme c'est que tu n'y connais rien et en parles quand meme.
Très bien, fais ce que tu dis et arrêtes de parler du logiciel libre.
Enfin, je tiens à te signalé que j'ai parlé de l'API de Windows après m'être informé. J'en parlais pour expliquer pourquoi "Linux tient tête à Windows" alors que Windows a facilement 100 fois plus de développeur que Linux.
M'enfin, tu as peut-être une autre explication. Les développeurs Linux seraient 100 plus doués que les développeurs Windows ?
Il y a moins d'un mois, je n'aurai rien dit de l'API de Windows et j'en ai rien dit jusqu'à ce que je lise la doc.
Si j'étais un anti-Windows primaire, je n'aurais pas dit que l'API de Direct3D est bien foutue ni que le noyau de Windows offre toutes les fonctionnalités qu'on attend d'un OS moderne.
De plus, j'ai passé sous silence DirectShow alors que ça va devenir mon "coeur de métier". En un mot : lourdingue. Tellement lourdingue que MS fournit une tripoté de classe pour simplifier le développement. Mais comme ces classes ne répondent pas à mon besoin... ça va être lourdingue.
Mais DirectShow est bien moins pire que l'API de Windows. Son historique l'a rendu lourdingue. M'enfin, il n'y a pas vraiment d'équivalent dans le libre. Sauf gstreamer mais ce n'est pas encore ça ; espérons que ça ne tarde pas.
NB : gstreamer est beaucoup plus récent que DirectShow. Je dis ça avec que tu te foutes de gstreamer.
# ESR
Posté par IsNotGood . En réponse au journal ESR passe sous ubuntu. Évalué à 4.
ESR n'est pas vraiment un homme de compromis, il n'aime pas "se fondre dans le moule" ou adhérer à un mouvement qui ne lui satisfait pas pleinement. Il a un fort caractère et peste souvent. En caricaturant il se prend pour une star... C'était un bon contributeur, mais sans plus. Mais il demande à Fedora ce que Fedora n'est pas.
http://www.redhat.com/archives/fedora-devel-list/2007-Februa(...)
Fedora n'est pas ça et ne veut pas ça. Fedora n'empêchera jamais personne de le faire, mais hors du projet Fedora. Il y aura peut-être une Fedora-Windows avec les codecs Windows en payant. Fedora ne l'empêchera pas. Mais la Fedora-Windows ne sera pas sous le chapeau du projet Fedora.
C'est peut-être prétentieux, mais Fedora veux être aux distributions (à l'OS GNU/Linux) ce que Linux est au noyau. Linux donne la cadence et ne s'adapte pas aux exigences non techniquement justifiées des drivers proprio. Linux est libre, libre de ses choix/évolutions. Pas de compromis dans ce domaine. D'où Linux qui casse souvent la compatiblité au grand désespoire de NVidia ou VMware (voir par exemple l'adoption de kvm et non de la solution binaire de VMware).
Une bonne réponse :
http://www.redhat.com/archives/fedora-devel-list/2007-Februa(...)
ESR exige quelque chose d'incompatible avec le projet Fedora.
Bonne route à ESR. Mais je crois qu'il sera aussi déçu par Ubuntu. J'ai le sentiment qu'il ne peut jamais être satisfait.
Le délicieux (ou féroce) Alan Cox :
http://www.redhat.com/archives/fedora-devel-list/2007-Februa(...)
Alan Cox m'impression toujours par le mordant de ses commentaires.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 1.
Admettons mais j'en doute puissament.
> Quel rapport avec l'OS et son architecture ? Si demain j'ecris un browser qui supporte ActiveX sous Linux, Linux devient mauvais architecturalement ?
Essais de proposer un brower avec ActiveX. Aucune distribution le fournira (sauf si MS fait une distribution Linux...).
> Justement, c'est toi qui interprete mal, l'OS le plus utilise est le plus attaque, ca ne veut absolument pas dire qu'il est le moins fout niveau securite, et rien ne prouve que l'OS le moins utilise soit le mieux foutu.
Dans les OS "le moins utilisé" il y a Mac. Ben Mac a peu de soucis de sécurité. Puis de tout manière dans quelque années Linux sera très utilisé (10 %) et on verra que cette esplication avec la popularité de Windows est du flan. A 10 % tu va dire que ce n'est pas assez. Ben on attendra que Linux soit à 90 % et ça sera encore le cas. Linux ne sera pas la catastrophe Windows (à 0,1 % de popularité comme à 99,9 %).
Si Windows était un OS "super secure" comme le dit la propagande, pourquoi il supporte si mal sa "popularité" ?
Si Linux est si naze, pourquoi dans la pratique il est si "secure" ?
Tu ne pourrais pas faire un petit virus pour Linux ou cracker Linux histoire de démontrer que linux n'est pas "secure". Un truc qui fait du bruit. Et si ce n'est toi, pourquoi pas un autre fan de Windows ?
Il parait que beaucoup de cracker Windows tourne sous Linux. Pourquoi pas l'inverse ? Et pourquoi il n'y a pas l'inverse ?
Beaucoup de gens détestent Windows. Mais comme il y a beaucoup d'utilisateur de Windows, on peut penser qu'il y a beaucoup de fan de Windows. Je me trompe ?
> Et sous Windows t'as les comptes LocalSystem, NetworkService, ....
Et le compte Service. Je crois que tu as avoir du mal pour en trouver d'autres.
> De nouveau, manque de connaissance total de Windows, il y a plein d'add-ons dispo
Par exemple ?
Je ne parle pas d'outil d'audit. Je parle d'add-on actif (comme SeLinux).
> ActiveX est inoffensif dans Vista
Il aura fallu attentre VIsta... Des années.
M'enfin, méfiance, à la sortie d'XP, XP était "secure" selon MS et résolvait tous les problèmes de sécurité des versions précédentes de Windows. L'histoire a jugé, et XP était naze.
> vu qu'IE tourne avec quasi-aucun droits
Tiens maintenant il "tourne avec quasi-aucun droits" alors que plus haut c'était sans aucun droit...
> quand au niveau de securite, IE te le donne, faut mieux regarder.
Non seulement il te le donne, mais tu peux aussi le changer. Que du bonheur...
> J'attends une explication sur quels problemes de securite dans _WINDOWS_ demandent un anti-virus, et en passant, MS ne donne pas d'anti-virus avec l'OS, c'est un achat separe pour ceux qui en veulent, ce n'est nullement necessaire.
Si ce n'est pas nécessaire, c'est alors une arnaque. Rires^W heu non, ce n'est pas rigolo. Microsoft arnaque les gens en vendant un antivirus.
Au fait, ce n'est pas MS qui fait tout pour qu'on ne puisse pas retirer IE du système ? IE qui est installé avec _WINDOWS_. Ce n'est pas MS qui clame haut et fort que IE fait parti intégrante de l'OS de _WINDOWS_ ?
Oui et oui. J'y peux rien, c'est MS qui le dit.
Au fait, ce n'est pas Windows lui même qui te conseil d'installer un anti-virus ?
Oui, le "Security Center" de _WINDOWS_, même quand je n'ai installé que _WINDOWS_, me le conseil ! Idem s'il n'y a que du Microsoft certified Geniune, etc, _WINDOWS_ me conseille d'installer un antivirus (sinon je met en péril mon système (dexit Windows)).
C'est n'est pas MS-Office (ou Acroreader, etc...) qui me conseille d'installer un anti-virus, c'est _WINDOWS_.
Un truc rigolo (limité à microsoft.com):
http://www.google.fr/search?hl=fr&q=site%3Amicrosoft.com(...)
38 000 pages avec "antivirus" !
Un autre truc rigolo (limité à redhat.com) :
http://www.google.fr/search?hl=fr&q=site%3Aredhat.com+an(...)
5 430 pages avec "antivirus" ! Mais je te laisse regarder les pages. Ça parle quasi exclusivement d'antivirus pour Windows... et rien pour Linux.
# Re:
Posté par IsNotGood . En réponse au journal Linux, communiste, ou non :p. Évalué à 2.
Politiquement parlent, le libre est plus proche du libéralisme que du communisme.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 1.
> a) separation user / kernel
> b) separation entre users
> c) notion d'administrateur / user avec acces limite
>
> Bref, architecturalement parlant, ils sont quasi-identiques la dessus.
J'avais raté ce grand moment...
Ta description est simpliste. Tellement simpliste que tous les OS multi-utilisateur la respecte.
Mais sous Windows il n'y a qu'une partie du système qui est protégée. Tu peux faire un "rm -r -f /" sous un compte avec Linux, il n'y a que ton compte qui est bousillé. Sous Linux, et n'importe quel OS respectable, c'est l'ensemble du système qui est protégé. L'utilisateur n'a pas un navigateur qui tourne sous le compte administrator comme Windows le fait et te demande s'il peut faire tel ou tel truc dangereux pour le système.
Impact :
Sous Linux on ne demande pas à l'utilisateur :
- voulez-vous faire ce truc dangereux ?
Sous Linux il ne peut pas et point barre.
Sous Linux il n'y a pas qu'un compte admin mais plusieurs. Le compte bin, mail, dbus, ftp, lp, postgres, etc...
Puis ça ne s'arrête pas à l'OS. Firefox/Thunderbird ne supporte pas ActiveX car c'est dangereux. IE/Outlook supporte ActiveX. L'un veut être sûr et l'autre semble s'en foutre royalement. Opera et Firefox n'ont pas de problème de sécurité (mais des bugs qui sont vites corrigés), IE a des problèmes de sécurité au niveau conception. IE a besoin d'un antivirus, les autres non.
J'imagine que tu vas encore dire que Windows est beaucoup plus utilisé que Linux et donc a plus d'attaque, etc...
C'est marrant que l'OS le plus utilisé, qui a le plus de ressource, soit le moins bien foutu niveau sécurité et que les OS les moins utilisés soient les mieux foutu niveau sécurité.
Tu m'expliques ?
Linux propose plein de add-on au système de sécurité par défaut pourtant robuste. Le plus connu est SeLinux. Pour Windows c'est un anti-virus...
Oui, si on est simpliste, Linux et Windows c'est la même chose. Mais si on gratte ça n'a pas grand chose à voir aussi bien technologiquement que par leur approche de la sécurité. Par exemple ne pas avoir d'ActiveX dans un navigeur, ne pas avoir un onglet d'option pour dire à quel niveau de sécurité on navige, etc...
Linux (idem pour Firefox, etc) n'hésite pas à casser la compatibilité s'il y a un problème de sécurité. Windows le fait en dernier recours et s'appuis sur les anti-virus. Anti-virus tellement indispensable de part la conception de l'OS que MS en propose un maintenant... La boucle est bouclée.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
D'accord. M'enfin, les stats ça change du jours au lendemain.
Exemple, au-dessus tu dis (sur la base d'une étude) que Linux a crû de 6.1 %. Sur la même période, le plus gros vendeur Linux fait du +40 % (chiffre absolu) !
Qui croire ?
Autre aspect a remarquer. Linux a été vite adopté par les geeks en tant que desktop (d'où une croissance rapide). Pour les geek, la partie est "gagnée". Je veux dire que Linux n'est plus une alternative exotique. Un geek qui utilise Linux, ça n'étonne personne. Au pif et sans le moindre chiffre, je dirais que Linux à 20 % des geeks ou hackers. Par contre en poste desktop pour monsieur tout le monde (la très grande majorité), c'est une tout autre histoire. Pour Linux y a, au pif et sans le moindre chiffre, 0,1 %. Donc pour arriver à 10 % il faut ... 16 ans.
> Le probleme c'est que les editeurs n'en ont rien a battre du 64bit jusqu'a ce qu'il commence a se repandre, le meme probleme que Linux a avec les editeurs.
Mais pourquoi les éditeurs (oracle, ibm, etc) font des versions 64 bits pour Linux et pas pour Windows ?
> MS met son poids dans la balance pour changer ca(Exchange 2007 est 64bits uniquement par exemple) mais ca prend du temps.
Il y a MS-Office en 64 bits ? Je n'en sais rien mais je ne crois pas.
Mais il y a bien openoffice en 64 bits pour Linux et il n'y a pas de version 64 bits pour Windows d'Openoffice.
Le fait est là, Linux à tout (ou 99,9 %) en 64 bits et Windows pas grand chose.
> le meme probleme que Linux a avec les editeurs.
Les éditeurs Linux font du 64 bits. Tu nous dis que Linux a gagné la partie pour le 64 bits ?
> Tout a fait, mais moi je parles techniquement, NT n'avait aucun probleme a passer a 64bits techniquement.
Ce que j'ai surtout voulu dire est que l'API (ce qui est vu par les programmes) sucks et rend difficile le portage d'une appli 32 bits vers 64 bits ce qui n'est pas le cas de Linux.
S'il est facile d'avoir des applis 64 bits sous Windows, pourquoi il n'y a pas MS-Office (j'imagine qu'il n'y a pas MS-Office en 64 bits, car en fait je n'en sais rien) ?
Linux a des ressources ridicules par rapport à Windows et pourtant tout est dispo en 64 bits.
> Combien est-ce que Redhat fait de chiffre d'affaire sur PPC et autres ? Rien du tout,
On dit que tu as raison. Mais si ça ne coute "rien du tout" à Red Hat d'avoir une version 64 bits, ils auraient tord de ne pas proposer du 64 bits. Si ça coute "rien du tout" pour avoir du 64 bits sous Linux, alors Linux est vachement bien foutu. Si ça coutait cher, Red Hat auraient tord de faire du 64 bits (surtout que Red Hat est ridicule à côté de MS) et ça fait depuis longtemps qu'ils auraient arrêté de le faire. Si Red Hat le fait, c'est qu'il y voir un intérêt et en monnai sonnante et trébuchante. Mais clairement Red Hat ne doit pas perdre d'argent.
Red Hat vend beaucoup de 64 bits. D'ailleurs pour RHEL 5 il y aura encore le support pour IA64 (ce qui montre que Red Hat a beaucoup vendu de RHEL 3 et 4 pour IA64).
> In what follows I investigate the state of UTF-8 support under Linux (especially Debian
Debian est l'un des derniers distribution a être passé à UTF-8 !
Red Hat est passé à UTF-8 depuis la Red Hat 8.0 ! C'est configuré par défaut depuis RHL 8.0. Puis il y a eu RHL 9, FC1, FC2, FC3, FC4, FC5 et FC6. Il n'y a pas encore eu de Debian stable en UTF-8 ! (OK, ça ne devrait pas tarder).
Aussi, RHEL utilise UTF-8 par défaut depuis RHEL 3.
Autre chose, Linux support UTF-8 (donc 2^32 caractères, c'est-à-dire tout unicode). Windows (et si mes renseignement sont bons) que UCS-2 (2^16 caractères). UCS-2 est insuffisant pour certain language (c'est pour ça que Unicode est passé à 2^32).
Sous Linux en mode texte ça concerne la libc. En mode graphique ça concerne principalement gtk (pango). Malheureusement OpenOffice ne supporte pas pango et Mozilla que via un patch non officiel (qui marche bien mais impact significativement les performances). Le patch est dans Fedora depuis FC2 (pour Mozilla) et activé par défaut depuis FC3.
Notons que Firefox est principalement développé pour Windows (normal, il y a beaucoup plus d'utilisateur).
Ceci dit le support d'Unicode est une tâche énorme (avec les problèmes lorsqu'on mixe des écritures de gauche à droite et droite à gauche, par exemple, etc...), donc qu'il y ait des problèmes ne m'étonne pas.
> Les MFCs sont moches
Tu me fous la trouille. Je n'ai pas encore regardé MFC. Mais si MFC est pire que le reste, ça fous vraiment la trouille.
> HINSTANCE et HMODULE sont identiques(les 2 existent pour des raisons de compatibilite avec Windows 16bit)
Ben les deux sont dans le dernier SDK platform de Windows... (de 2006).
Je ne crois pas que quelqu'un va installer le dernier SDK de Windows pour faire une application 16 bit.
Ces trucs ne sont qu'un pointeur sur l'adresse du début du programme ou dll. Tout un poème.
> L'API il t'es difficile a retenir parce que tu debutes
Non. Par exemple DirectX, plus spécifiquement Direct3D, passe très bien. Et pourtant j'y connaissais rien dans le domaine des cartes graphiques.
Exemple : Dans Linux tout ce qui est thread débute par pthread. Sous Windows c'est une autre histoire.
Sous Linux il n'y a que le pid du thread. Sous Windows il y a l'HANDLE et le pid (parfois nécessaire pour quelques fonctions).
Regardes les fonctions liés à la mémoire sous Windows et compare avec Linux. T'as même un LOCALHANDLE... Des relant de Windows 16 bits dans le dernier SDK de Windows...
Pour le multi thread il y a les CRITICAL_SECTION/EnterCriticalSection/LeaveCriticalSection mais ça ne marche que pour un processus. En interprocessus, il faut autre chose (via les Event). Sous Linux, c'est la même chose pour intro-process et inter-process, tu dis seulement si tu veux que ça marche en inter-process (donc passage par le noyau systèmatique) ou non. C'est tout. La librairie C fait les appels système qui vont bien dernière. Si tu veux passer d'un processus à plusieurs, ça se passe comme une lettre à la poste.
> c'est l'utilite des typedefs: le compilo t'avertira si tu passes un HANDLE a une fonction qui veut un HINSTANCE.
C'est gentil ça. Un timer (event) et un process a le même type sous Windows. En fait tous les "objects systèmes", selon la terminologie MS, a le type HANDLE. Tu peux passer un timer ou un block mémoire à la place d'un process ou d'un fichier, le compilo ne voit aucun problème. Ce n'est en rien le cas sous Linux et fort heureusement.
Les typedefs Windows en utilise des tonnes et pour des conneries. Par exemple pour char il y en a plus d'une dizaine !
Linux utilise beaucoup de typedef (probablement plus que Windows) mais pas pour des conneries (comme DWORD qu'on trouve partout ce qui doit poser de gros problème de portabilité). Linux utilise des typedef là où c'est pertinant : quand le concèpt est différent. Un pid même si c'est stocké réellement dans un int (DWORD dans le language Windows) n'est pas un int, pour des raisons de portabilité, d'évolution système (lorsque le pid passe de 16 bits à 32), etc.
Autre chose rigolote, c'est DWORD. C'est un int ou un long ? Ben je crois que même MS n'en sait rien. Ce n'est pas un problème en soit. Surtout que sur du 32 bits int=long. Mais pour 64 bits on peu avoir par exemple sizeof(int) = 4 et sizeof(long) = 8. Donc le diff de deux pointeurs ou une taille mémoire n'est plus un int (DWORD) mais un long. Ben avec tous les DWORD dans l'API de Windows qui désigne des concepts différents (nombre, quantité de mémoire, etc), ça doit foutre un sacré bordel.
Linux (en fait POSIX) n'a pas ce problème. Si tu codes correctement, passer de 32 bits à 64 bits (que sizeof(int) soit 4 ou 8, qu'importe), passe comme une lettre à la poste.
Autre problème, Windows semble avoir des conventions de nommage mais elles sont peu respectée. Exemple : utiliser le préfix P pour le pointeur alors que c'est rarement utilisé. Les types qui sont parfois uniquement en majuscule et parfois un mix. Normalement ce qui commence par '_' est à usage interne d'une lib système (une appli ne doit pas l'utiliser !), ben sous Windows pas forcément, etc...
De ce que j'ai vu jusqu'à maintenant il n'y a que Direct3D qui est une bonne API (et pourtant Direct3D est particulièrement complexe ce qui ce comprend très bien).
Quand on sait que les constructeurs de hardware sont très impliqués dans le développement de Direct3D, on comprend que Direct3D n'a pas le "Windows touch".
[^] # Re: Des Frameworks et de leurs places dans la vie virtuelle
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 3.
Je suis assez d'accord.
Mais il faut aller un peu plus loin. Deux implémentations pour le même service c'est sans intérêt, et pire ça peut nuir. Mais par exemple il y a plein de window manager sous Linux. Ça nuit ? Ils n'offrent pas la même chose. Ici c'est du choix pour l'utilisateur, c'est un plus.
Par contre entre gtkmm et qt, c'est limite doublon. M'enfin, qt est utilisé depuis longtemps, utilisé par KDE, et donc restera longtemps. gtk+ et qt n'est pas un doublon. L'un est pour les développeurs C et l'autre pour les développeurs C++. Il y a effectivement quelques doublons dans le logiciel dont l'un des plus populaire est dpkg et rpm.
Un des "problèmes" est qu'il ne faut pas interdire les initiatives même si elle semble faire doublon. Sinon on tu la concurrence.
Puis il faut aussi remarquer que les projets libre ont naturellement tendance à suivre les standards et non réinventer la roue. Les différences ne sont jamais introduites pour rendre les utilisateurs captifs.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
Je fréquente ce site. Et comme beaucoup ici (même si on n'est peut-être pas la majorité mais on doit être un part significative) je ne dis pas que Linux est au top pour le desktop et va tout déchirer dans les semaines à venir. D'ailleurs des journaux avec "Linux est-il près pour le desktop ?", etc... on en voit des tonnes.
> Tu sais, ces memes gens qui trouvent 3342 excuses pour expliquer pourquoi Linux ne decolle pas
Là tu fais une erreur. Linux décolle. Mais il est parti à 0,01 %. S'il grippe à 33 % par ans (ce qui est fort respectable), il faut plus de 8 ans pour arriver à 0,1 %, et encore 8 ans pour arriver à 1 %, et encore 8 ans pour arriver à 10 %. Donc il faut 24 ans !
Il suffit de bases minimum en mathématique pour savoir ça.
> C'est surtout toi qui ne sais pas du tout ce que MS fait, passer NT a 64bits etait tres simple, ce qui etait plus complique c'etait avoir un support de drivers decent vu qu'on ne les ecrit pas, generer tous les tests necessaires et avoir un support pret pour gerer pour ca.
Ben c'est que je dis. Linux a 64 bits (avec drivers et des tonnes d'applications) depuis longtemps et pas Windows. Il y a une offre pour entreprise en Linux 64 bits. Windows c'est récent.
Pourquoi Windows peine à avoir des applis et des drivers 64 bit ?
Car les éditeurs de logiciel et de driver trainent la pate ? C'est seulement à cause de ça ? Probable que l'API windows sucks car si j'ai bonne mémoire, la version Alpha de Windows tourne en 32 bit pour les int... Alors que le int naturel d'Alpha (son mot machine) est en 64 bit sur les unix (idem pour Linux). C'est juste un exemple...
> De nouveau, rien a voir, tu sais depuis quand MS avait un NT 64bits en interne ? Depuis quand NT supporte les technos VT ? Non, tout ce que tu regardes c'est ce qu'on vend, et les releases elles dependent de bcp d'autres criteres en plus de "c'est pret techniquement".
L'argument est pertinant. Mais je parle d'offres aux entreprises (désolé, je ne l'ai pas signalé plus haut). Je ne parle pas d'un truc qui marche au fond d'une université. Je sais qu'il faut du temps entre l'innovation et son déployement.
Red Hat 7 (voire encore plus vieux) proposait au entreprise i386, Alpha, Mips (peut être plus encore). RHEL 4 propose i386, AMD/Intel 64, PPC32, PPC64 et peut-être encore d'autres.
> Linux ? Qui ca le kernel ? Parce que des softs Linux qui ne gerent pas UTF-8 j'en connais plein
Exemple ?
Xbill ?
Qu'es-ce qui ne supporte pas UTF-8 dans Linux et qui est utilisé ?
Pas grand chose.
> Linux ? Qui ca le kernel ? Parce que des softs Linux qui ne gerent pas UTF-8 j'en connais plein, et un OS c'est legerement plus qu'un kernel.
Et il y a presque rien d'UTF-8 dans le noyau (pour ne pas dire qu'il n'y a rien). À part certains trucs pour les noms de fichiers, les terminaux, et guère plus (et je crois que ça doit être moins ça...). UTF-8 on le trouve en premier dans la libc, pas dans le noyau. Et d'ailleur ça ne doit pas conserner le noyau (à quelques exceptions près).
Clairement quand je parle d'UTF-8, je ne parle pas du noyau. Un noyau sans UTF-8 (si un noyau avec existe) ne doit pas poser de problème pour faire tourner une applie UTF-8.
> L'architecture que propose Linux est quasi-identique a l'architecture de Windows
Diantre, Microsoft, ton maitre, dit que Linux est une technologie de 30 ans et que Windows c'est tout beau tout moderne.
MS c'est trompé, ou c'était encore un gros FUD, ou Linux a rattrapé ses 30 ans de retard en moins de 10 ans ?
Les OS (noyaux) sont proches du hardware donc les OS sont proches pour certaines parties. C'est un fait.
Mais sous Linux on n'a pas de C: D: etc...
Sous Linux il y a les pseudo-terminaux.
Sous Linux il y a select().
Sous Linux il y a les signaux.
Sous Linux il y a etc...
Sous Windows il y a etc... (à toi de remplir cette partie).
Entre un Unix commercial et Linux il n'y a pas beaucoup de différence. Par contre entre Windows et Linux (et les Unix en général) il y a de grosses différences.
Ceci dit, comme je me documente sur Windows, je dois reconnaitre que le noyau de Windows fournit ce qu'on attend d'un OS "moderne". Par contre pour l'API bas niveau (tout ce qui est équivalent à glibc) c'est beurk. Les noms de fonction sont bizarres, il y a des HANDLE (void*) partout, des fonctions qui attendent un HINSTANCE (void *) fournit pas main() (diable, pourquoi la libc de Windows ne gère pas ça !), il y a des structures et des fonctions avec des membres/paramètres réservés, ou il faut la renseigner avec sizeof(struct), etc... Quel est la différence entre un HANDLE un HINSTANCE et HMODULE ?
J'ai rarement (jamais ?) vu API aussi moche. Et c'est diablement difficile à retenir.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
On peut aussi rendre autoconf dépendant de gcc, de libstdc++, de libxml2, avoir une interface graphique en gtk+ ou qt, etc...
On peut. C'est blindé de dépendances circulaires s'il faut construire depuis les sources "from scratch", mais oui, on peut. Après je ne te dis pas l'enfer que c'est de maintenir une distribution...
> Qu'autoconf serve a compiler gcc n'y change rien, ils s'amusent pas a partir d'une machine nue
Ben avec Gentoo oui (pour donner un exemple).
Autre chose, si tu installes des outils GNU sur un unix commercial, et si autoconf exigerait gcc, etc, alors je ne te raconte pas l'enfer.
Normalement les unix commerciaux ont : shell, awk, sed, m4. Ce que demande autoconf.
> le bootstrap du compilo c'est pour le compilo
Pour le bootstraper gcc, gcc utilise le compilateur fournit par l'unix commercial ou Windows. Gcc n'utilise pas gcc (mais il peut, ce qui se fait avec Linux).
Si j'ai bonne mémoire gcc fait :
cc (compilateur fournit avec l'OS) => gcc stage1
gcc stage 1 => gcc stage 2 (final)
Autoconf fait partit des quelques programmes GNU qui doivent avoir le minimum de dépendance. Idem pour gmake par exemple qui est exigé par beaucoup de projet (NB : gmake n'existe pas gcc).
D'ailleurs sous GNU/Linux ont fait en sorte d'avoir le minimum de dépendance circulaire. Sinon ça pose de gros gros problèmes pour maintenir les distributions.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
En un sens tu as raison. Mais les programmes (donc les sources) peuvent avoir besoin de savoir si on est en 32 bits ou 64 bits, s'il faut activer l'option LARGE_FILE (cas 32 bits) ou non, si on est en big ou little endian, etc...
Autoconf fournit ces informations.
Après, il faut aussi que les programmes soient conçu pour 32 bits et 64 bits.
M'enfin quand on voit comme les outils libres tourne sur plein de plateforme/OS, on se dit que c'est aussi grace à autoconf.
> je dirais que c'est plutot grace a gcc.
Pour compiler gcc, gcc utilise autoconf.
> les autotools beuark quoi,
Ben fais mieux. Certe autoconf c'est moche. Mais il faut pouvoir installer et faire tourner autoconf avec trois fois rien. On ne peut pas demander à autoconf d'être écrit en C ou C++ (puisque pour compiler le compilateur il faut autoconf). Actuellement autoconf demande sh, awk, m4 et optionnellement perl et imake (si j'ai bonne mémoire).
> c'est mon optinion mais je pense que je la partage avec un certain nombre de personnes.
Et tout ces gens n'ont pas proposé mieux...
[^] # Re: ...
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
Sous Fedora il y a une tache de fond qui regarde s'il y a des mises à jours. En fonction de la configuration il downloade les paquets voire les installe aussi. Il peut aussi en informer l'utilisateur via syslog, mail ou dbug. S'il n'y a pas d'installation automatique de démandé, l'utilisateur est informé qu'il y a des mises à jour via une applet sur le bureau (communication via dbus). Il clique dessus et lance la mise à jour (optionnellement en choisissant les paquets à mettre à jour).
A ma connaissance, il ne fait pas de reboote. Mais je ne serais pas étonné qu'il y ait une option dans un coin pour le faire.
[^] # Re: Mes benchs à moi
Posté par IsNotGood . En réponse au journal Choix d'un système de fichiers. Évalué à 2.
> - perte de donnée
C'est marrant. Un mec fait un test avec ext3 et a des pertes de données. De nombreuse (million?) personnes utilisent ext3 et n'ont pas de pertes de données (ou c'est très rare).
> - corruption totale d'une partiton de 67Go !
cf ci-dessus. Si ext3 était naze, tu crois que Red Hat l'utiliserait ? Red Hat l'utilise pour des données critiques sur des gros serveurs et doivent tourner 24/24 7/7 365/365.
> (alors que je faisais des sync régulier pour l'éviter et aucune freeze lors de ces sync)
Si t'as un système qui freeze, alors tu as d'autres problèmes. Problème hardware ou problèmes qui écrit n'importe où en mémoire. Dans ce cas tous les FS peuvent se planter (avec perte de données et tout).
Il y a eu le cas avec ext3. Le module ntfs (même en ro) écrivant n'importe ou en mémoire et foutait la merde dans les données d'ext3. Il y a eu des cas de FS irrécupérable. NB : ntfs a été corrigé.
Il y a eu aussi ce problème avec le module NVidea.
> - pas de fsck de 3h, tu remonte et paf c'est finis
Avec ext3, ce n'est qu'une question de configuration. Fais "man tune2fs" et "man fstab".
Sans fsck complet, il est impossible pour un FS de détecter un problème hardware (sauf via le retour des fonctions read() et write()). Donc un fsck régulier, même s'il n'est pas exigé par le FS, ne peut pas faire de mal. Loins de là.
> je tourne en 2.6.20tmb
Ben si tu tournes avec des noyaux en développement, plus du "bleeding edge", il ne faut pas s'étonner qu'ext3 (ou n'importe quel fs) plante.
# Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 8.
> On entend souvent dire que le GNU/Linux c'est over-top super trop méga-bien pour le desktop.
Qui dit ça ?
Linus Torvalds qui a dit à mainte fois que rendre Linux compétif dans le desktop est un énorme chalenge ?
Mandriva qui fait du desktop mais ne décolle pas financièrement ?
Red Hat qui fait du pognon mais ne fait pas de Desktop (ou marginalement) ?
Les 0,2 % de poste desktop sous Linux ?
L'absence de l'implication des constructeurs de périphérique "desktop" dans Linux ? (voir le difficulté qu'a Linux pour avoir un Wireless correct).
Dell qui investi dans Linux mais que pour les serveurs ?
Bob Young (créateur de Red Hat) qui a dit que Linux ne serait jamais pour le desktop ? (c'était il y a 7 ans je crois).
> pourquoi sa progression n'est pas aussi importante qu'on pourrait l'espérer.
Qui espérait une progression importante ?
Personne dont l'expertise en reconnue. On s'attend à une montée lente. Ça commence à se mettre en place. Le déploiement de 20 000 postes chez Peugeot est un signe significatif. Je pense que les assurances vont probablement suivre. Mais comme d'habitude, ça va prendre du temps.
> Je suis un peu déçu de n'avoir pas vu ces questions posées plus tôt sur ce genre de forum. C'est comme s'il y avait une sorte de tabou
Absolument pas. Les plus avisés savent que GNU/Linux n'est pas méga-génial pour le desktop. Mais il ne faut pas compter sur les supporter du logiciel libre (dont je fais parti) pour dire que GNU/Linux c'est de la merde.
> pas (ou peu) de développeurs, pas (ou peu) d'applications ; pas d'applications, pas d'utilisateurs ; pas d'utilisateurs, pas de développeurs.
Sauf que GNU/Linux a de plus en plus de développeurs, que le libre a de plus en plus d'adeptes, etc...
Mais ça tu oublies de le mettre dans ton équation.
Tu parles d'un déclin et tu te trompes. Linux grippe et depuis longtemps. Le plus gros fournisseur Linux fait au moins du +30% par an depuis de nombreuse année. Un résultat de progression bien supérieur à MS. Linux prend des parts de marché à MS dans les serveurs. Il avait été prédit que Windows NT et ses successeurs allaient tout bouffer dans le domaine serveur. Ben ce n'est pas le cas. Et ce n'est pas qu'une question de temps. D'un succès garantit de Windows NT (puis 2000, 2003), on est maintenant passé à une position fragile pour Windows dans le domaine des serveurs.
> [blabla autoconf] Sauf que je pense que les mots ne sont pas assez durs pour dire combien ce truc est pourri
Il est unique mais il est pourri...
C'est celà oui...
MS en chie comme un con pour fournir une version 64 bits de son OS, Linux fait ça les doigts dans le nez grace entre autre à autoconf (on a tout en 64 bits sous Linux et depuis longtemps : noyau, libc, base de donnée, bureau GNOME/KDE, etc), mais tu conclus que autoconf est pourri.
On a du GNU/Linux partout. Sur i386, sur AMD64, sur PPC32/64, sur ARM, sur Alpha, etc... alors que autoconf est pourri selon toi.
Pour Windows il n'y a pratiquement rien. Il y a une version Alpha (qui tournait principalement en 32 bits....) et un version Mips. J'ignore si cette dernière variante a vu vraiment le jour.
> Mais là encore, sous Windows et Mac OS on trouve une tétrachié d'outils pour faire du déploiement d'applications convivial (pour le développeur et l'utilisateur).
C'est un blague ?
Faire un paquet rpm ou apt est 10 fois plus simple que de se casser les couilles avec les salopries fournies par MS.
Si rpm ou apt était pourri, tu m'expliques pourquoi on voit tant et tant de paquet rpm ou apt ?
Bon, j'arrète là de lire ton journal. Il y a connerie sur connerie pour les aspects techniques et ça me souale. D'autant que tu parles de développement sous Windows, et moi qui développe aujourd'hui sous Windows (faut bien manger), ben c'est la galère. L'API est immonde (sauf DirectX ceci dit). Apprendre l'API de Windows est un chemin de croix.
C'est depuis que je développe sous Windows que je comprend pourquoi Linux dans une certaine mesure tient tête à Windows. Linux tient tête à Windows car l'OS et son API est beaucoup mieux foutu. L'écart est si énorme, que même s'il y a plus de 100 développeurs Windows pour 1 développeur Linux, ça permet à Linux d'avoir son mot à dire. Si on ne connait pas Windows et Linux, si Windows à 100 fois plus de développeur que Linux (ce qui doit être le cas) on peut se dire que Linux va être balayé.
Si Linux s'impose sur le long terme, ça sera grace à son innovation.
Prends rpm ou apt.Tu les critiques mais quand on y a goûté, ça casse les couilles de passer sous Windows. Et ça les casse gravement.
Pourquoi il n'y a pas l'enfer DLL de Windows sous Linux ? Car Linux a une bonne gestion de version des librairies. Windows n'a presque rien (il y a un truc récent avec les manifest) et c'est pour ça que Windows c'est l'enfer. Pas car Windows a obligation d'avoir une API stable. Linux l'a aussi dans certains domains (glibc, x11, gtk, gnome, kde etc). Red Hat propose des systèmes avec une API binaire et source qui ne bouge pas durant 7 ans et aussi au niveau noyau.
L'enfer DLL de Windows, c'est seulement car Windows sucks. Un exemple, tu sais comment on fait pour passer de Direct3D v8 à v9 ? Ben on change tous les noms des fonctions, des types, etc... Mais même après ça, il n'y a tout simplement pas compatibilité ascendante. C'est ça une politique de compatibilité ?
C'est gentil de parler de la stabilité API de Windows. Mais il faut y regarder à deux fois pour voir qu'il n'y a rien de particulier ou magique.
L'innovation est ce qui va apporter le succès à Linux. Innovation qui permet la modularité. Modularité qui permet entre autre à Linux d'être un succès dans l'embarqué même s'il y a Windows CE. Modularité/innovation qui permet de faire OLPC. OS bien conçu qui permet d'avoir un support pour les nouveaux CPU 64 bits très tôt. OS bien conçu qui permet à Linux d'être le premier à supporter les technologie VT d'Intel et AMD. OS bien conçu qui permet à Linux de faire un carton dans le domaine des cluster (Windows y est maintenant marginal). Modularité/innovation qui permet d'avoir des distributions bien distinctent pour répondre à des besoins spécifiques (voir Gentoo par exemple). Innovation qui permet à Linux d'avoir un système au top pour le réseau (Linux supporte IPV6 bien avant Windows). Innovation qui permet à Linux d'avoir un système au top pour tout ce qui est lié à lvm. Innovation qui a permis GFS, FUSE, etc... Innovation via la disponibilité des sources qui permet à Google d'exister. Sûr que ce que fait Google avec Linux, Google ne pourrait le faire avec Windows.
Il y a plein d'innovations dans Linux qu'on ne retrouve pas dans Windows. Depuis quelques temps le projet stateless suit son court. Il est en phase de développement. C'est une innovation significative qui a moyen terme va séduire beaucoup de décideur/administrateur comme ils ont été séduit par rpm/apt qui permet de gérer ce qui est installé sur les bécanes sans se prendre la tête.
Autre point fort de Linux, et ce car globalement Linux refuse d'être un adèpte de la compatibilité binaire, sa rapidité à déployer les innovations. Linux est passé de linuxthread à NPTL sans grosse difficulté. La gestion fine de librairie a permis de fournir linuxthread et NPTL en parallèle durant la transition.
Linux est passé à UTF. C'est UTF-8 (codage de 1 à 6 octets pour compacter le donnée, mais ça tout UTF-32 qui est dispo) et couvre tout unicode. Windows ne supporte que la version 16 d'unicode.
Mon sentiment, ce n'est qu'un sentiment mais il est fort, est que GNU/Linux va gagner grace à l'innovation et pas car OS n'est pas cher. Un OS gratuit mais avec un TCO élevé ou qui n'offre pas de service attractif, est sans intérêt.
Certe, pour le Desktop Linux sucks aujourd'hui. Il ne sucks pas gravement. L'architecture que propose GNU/Linux est aujourd'hui solide et sans virus (virus : ça mérite un journal complèt quand on parle de Windows, et une ligne quand on parle de Linux). Les fondations de GNU/Linux (via le noyau, udev, hal, dbus, freedesktop pour les standards) sont OK pour un succès dans le desktop. Elle sont plus qu'OK et dépassent même Windows pour tout ce qui est périphériques amovibles (merci Linux 2.6/udev/hal). Mais ce qu'il manque cruellement à Linux, c'est le support des fabricants de périphérique. Fabricants qui misent tout ou presque sur Windows et un peu Mac. Chose compréhensible puisque ces OS trustent le desktop.
Mais dès que Linux prendra une parte significative dans le desktop (5 % suffit), la tendance peut s'inverser rapidement. Et lorsque ça arrivera, ça se remarquera comme c'est arrivé pour Linux dans les serveurs.
> il m'a fallu du temps pour comprendre que c'était la version de l'éditeur de lien dynamique (ld.so) qui avait changé entre temps.
Il n'a changé qu'une fois depuis que j'utilise Linux (depuis 10 ans) !
Mieux, tu peux toujours installer l'ancien éditeur de lien (ce n'est qu'un fichier (ld-1*.so)). J'ai fait tourner des programmes pour Linux 1.0 (0.99 en fait) sur des bécanes avec Linux 2.6. Ça marche comme un charme.
[^] # Re: Linus en fait-il trop ?
Posté par IsNotGood . En réponse au journal Linus et Gnome, Round 2. Évalué à 10.
Je ne te donne pas tord mais il faut voir les choses plus en profondeur. Si l'interface est surchargée mais puissante, c'est (peut-être) tant mieux. On peut voir ça avec certain logiciel (type outils de développement).
Plus d'option, c'est plus de choix plus de posibilité. Gnome n'est pas contre le choix et fournir plus de possibilité.
Mais quel choix et à quel coût ?
Exemple :
J'ai un logiciel de gravage (c'est un exemple fictif). Lorsque je le lance il me laisse choisir le graveur à utiliser. C'est bien. Mais s'il y a une galette que dans un graveur et rien dans l'autre graveur, c'est con. Il est claire que je ne vais pas graver avec le lecteur qui n'a pas de galette. On a une option inutile. Inutile si on a un moyen de detecter la présence de galette. Au-lieu d'imposer l'option, le mieux est d'avoir un moyen pour detecter la présence de galette. S'il y a deux galettes on propose à l'utilisateur de choisir, s'il n'y a qu'une galette on ne lui propose rien, et s'il n'y a pas de galette, on lui demande de mettre une galette (il choisi le graveur qu'il veut). Cette description est naïve si sur le bureau il y a des icones qui représente les graveurs.
Le logiciel de gravage me permet de choisir la taille du buffer à utiliser. C'est bien car la gravage peut planter si le buffer vient à se vider. Mais en réfléchissant un peu, c'est con. On a une fonction pour graver mais elle peut ne pas marcher. Donc cette fonction est buggée (du moins vu de l'utilisateur). Il faut corriger cette fonction pour qu'elle marche tout le temps et ainsi on fout la paix à l'utilisateur.
On peut multiplier les exemples. Beaucoup d'options sont souvent là pour corriger des déficiences. Ce que ne veut pas Gnome, et plus que de ne pas surcharger l'interface utilisateur, est d'avoir une interface pour pallier à des déficiences du système sous-jacent. Donc au-lieu d'ajouter une option, Gnome bosse sur les "fondations" du bureau. C'est-à-dire des parties non visible, sur le système sous-jacent. Un excellent exemple est HAL. L'utilisateur ne voit pas HAL mais HAL enrichi énormément le système sous-jacent ce qui permet une intéraction "intelligente" entre le bureau et le système sous-jacent. Ce qui permet de virer des options. Pour virer quelques options, il a fallu développer udev/dbus/HAL. Un énorme travail ! Et pas pour limiter l'utilisateur, pas pour lui proposer moins de possibilité !
Un projet comme Gnome n'est pas qu'une surcouche graphique du système d'exploitation. Ses ramifications s'étalent un peu partout dans le système et on ne peut que se féliciter de l'implication de Linus.
D'où des projets comme freedesktop. Fournir un système sous-jacent adapté à un bureau.
Certe Gnome peut être irritant. Il peut être rapide d'avoir quelque chose de fonctionnel en ajoutant une option. Gnome le refuse. C'est irritant mais ça a aussi une vertue. Ça pousse les développeurs à corriger les défauts là où ils sont.
Ce qui est important, c'est que la webcam marche, que le wifi marche, etc... Pas que ça marche en bidouillant des fichiers et en triturant 40 options au petit bonheur la chance, mais que ça marche lorsque c'est monsieur tout le monde qui le met en oeuvre. Ceci est valable pour Windows, KDE, Gnome, Mac OS, etc...
Ceci est de très très loins le plus important aux yeux d'un utilisateur. C'est ça l'objectif "ultime" de Gnome. Que ça marche ! Pas que ça marche en ajoutant une rustine (une option), mais que ça marche "out of the box". Et c'est ça que les utilisateurs veulent ! Qu'ils soient geek ou que ce soit ma grand-mère. Le problème de Gnome ou de n'importe quel bureau libre (KDE, XFCE, etc) n'est pas le manque de l'option bidule ou que le double clique sur prout fait crak ou bling. Il suffit de voir le succès de Windows pour se convaincre que ce n'est pas en ajoutant l'option bidule ou le double clique qui fait bling que GNU/Linux va attirer des utilisateur de Windows de façon massive. Ce dont ne se rend pas compte le geek assoifé d'option d'aujourd'hui, est qu'il y a des tonnes et des tonnes d'options qui sont passé à la poubelle avec l'évolution de GNU/Linux et pour le bien de GNU/Linux.
Les options virées en corrigeant le système sous-jacent porte peu à discussion en général. Du moins une fois que le système sous-jacent est corrigé.
Mais il y a un autre type d'option et qui est d'ordre "culturel". Un Windowsien n'ira jamais demander de pouvoir programmer des options en fonction du bouton de la sourie utilisée. Ça ne lui manque pas, il n'y pense pas. C'est accessoire. OK, ça peut être important pour tel ou tel utilisateur (voir Linus par exemple :-)). OK, ça peut être plus que culturel et un vrai atout pour la productivité de l'utilisateur. OK, les développeurs de Gnome peuvent y répondre et ils pourront se dire qu'ils élargissent le nombre d'utilisateur potentiel tout en augmentant leur productivité.
Mais ça a un effet de bord, parmis d'autres, non négligable. Ça augmente le ticket d'entré pour utiliser le bureau. S'il y a plein d'options, pleins de concept à la vue de l'utilisateur, ce dernier est obligé (en tout cas il se sent obligé) d'assimiler tous ces concepts/options. Cette profusion d'options/concepts/fonctionnalités aussi utile et justifiée par telle ou telle catégorie d'utilisateur, ajoute de la confusion. Au-lieu d'avoir un bureau convivial, on a un "truc" intimidant.
D'un côté l'ajout d'option/fonctionnalité semble élargir le nombre d'utilisateur potentiel, et d'un autre sa diminue le nombre d'utilisateur potentiel. Il y a un compromis entre fonctionnalité et simplicité/convivialité. On peut trouver que le curseur est un peu trop à droite, un peu trop à gauche, que KDE l'a placé pile où il faut et que Gnome est à côté de la plaque, etc...
Sans étude aprofondie et lourde à mettre en oeuvre, on est dans le subjectif pour savoir où il faut placer le curseur. Mais avant de juger, il faut déjà voir les intentions. Et l'intention de Gnome n'est pas d'être le bureau préféré des développeurs noyau.
Par contre, on peut affirmer qu'un bureau adapté à tout le monde est impossible à réaliser. C'est pour ça que la réaction de Linus, et sauf tout le respect que je lui voue, m'énerve passablement. Dire que tous les utilisateurs doivent utiliser KDE est une connerie. Dire que tous les utilisateurs doivent utiliser Gnome l'est aussi. Dire que Gnome prend ses utilisateurs pour des cons est une connerie. C'est respecter les utilisateurs que de proposer quelques choses de simple/accessible et non les prendre pour des cons.
La BMW de Linus doit avoir un système anti-dérapage préréglé qui ne lui permet pas de jouer avec les 150 paramètres utilisés en interne par ce système, les amortisseur sont peut-être pilotés, une clim qui répartit la température de sortie des buses vers la tête et les pieds (alors qu'il pourrait y avoir un potentiomètre pour régler ça), il n'y a que deux vitesses pour les essuis-glaces (alors qu'on pourrait avoir un potentiomètres), etc... Naïvement on peut dire que tout ceci limite l'utilisateur. L'utilisateur avertit dira que le réglage anti-dérapage ne lui convient pas et qu'il est dommage qu'il ne puisse bidouiller avec ses 150 paramètres, qu'il n'y a pas de réglage d'amortisseur qui correspond aux pavés de son village, que la clim lui chauffe trop les pieds et qu'il est dommage qu'il ne puisse pas bidouiller la puce qui régule la clim, que les vitesses préréglées pour les essuis-glaces ne sont pas adaptées au crachin de sa région et qu'il est dommage que ne puisse pas la réglée, etc... Mais ce n'est pas prendre l'utilisateur pour un con. Sinon BMW a pris Linus pour un con et le tout en lui piquant une somme bien rondelette (beaucoup plus que Gnome:-)).
Mais ce que fait BMW (et beaucoup) es-ce limiter l'utilisateur ? Ça dépend de l'utilisateur. Si l'utilisateur est un amateur/expert en voiture (type Alain Prost) alors oui. Si l'utilisateur est un consommateur/utilisateur de voiture moyen (type Linus) alors non. Si pour conduire ma voiture je dois lire un manuel de 500 pages et passer 15 minutes à configurer le bousin avant de démarrer, ben je suis très limité dans l'utilisateur de ma voiture. Et le vendeur de la voiture m'a pris pour con.
[^] # Re: « Reste à voir les réactions des développeurs. »
Posté par IsNotGood . En réponse au journal Linus et Gnome, Round 2. Évalué à 6.
Je ne vois pas pourquoi tu dis ça. Linus c'est trompé de mailing, ce n'est pas un drame. Il ne connait pas les arcades de Gnome et on ne va pas lui reprocher.
Il fournit des patchs, qu'il en soit bénit :-)
Les développeurs Gnome ne vont surtout pas s'en plaindre. D'autant que Linus est un "géni" pour ce qui est coder.
Une bonne âme a poussé les patchs de Linus dans bugzilla :
http://bugzilla.gnome.org/show_bug.cgi?id=408898
NB : Linus ne veut pas créer un compte bugzilla (ça l'emmerde de créer un nouveau compte et globalement il n'aime pas bugzilla).
Des patchs ont été validés, d'autres sont en cours de discussion.
Linus n'aime pas l'"esprit" Gnome. Il n'a pas sa langue dans sa poche (tant mieux) et son style de communication est disons brutal, mais les arguments souvant percutant.
Cependant, il devrait avoir en tête qu'un bureau qui ne lui satisfait pas, n'est pas un bureau qui ne satisfait personne, et que ce qui fait son bonheur, ne fait pas le bonheur de tout le monde.
[^] # Re: Linus en fait-il trop ?
Posté par IsNotGood . En réponse au journal Linus et Gnome, Round 2. Évalué à 3.
J'ai du mal à voir Linus se plaindre d'un truc qu'il n'utilise pas et encore moins faire un patch pour corriger ce qu'il n'utilise pas.
[^] # Re: Linus en fait-il trop ?
Posté par IsNotGood . En réponse au journal Linus et Gnome, Round 2. Évalué à 3.
J'étais fatiqué. Désolé.
Merci d'avoir fait l'effort de décrypter mon message pour tous :-)
[^] # Re: Linus en fait-il trop ?
Posté par IsNotGood . En réponse au journal Linus et Gnome, Round 2. Évalué à -10.
En l'utilisant pour des babioles, vous le vider de son sens, vous le banalisé.
[^] # Re: Fantastique!
Posté par IsNotGood . En réponse à la dépêche Bitfrost : Un nouveau modèle de sécurité. Évalué à 2.
Fais le, ça ne me choquera pas du tout. Et je suis convaincu que la grande majorité des pays pauvres te laisseront faire.
Surtout ne propose pas de support, sinon tu vas exploser ton budget. Le moindre pépin va coûter au moins 5 000 ¤ (et oui, ils n'ont pas de SSII, d'Internet, de courrant, etc). Et comme en plus tu fais tout pour ne pas les éviter...
En Europe on peut tolérer d'augmenter le prix d'un PC de 50 voire 100 ¤ pour le support. Mais pour OLPC, ce n'est pas tolérable. La bécane doit être blindée de chez blindée.
Fais cadeau de PC sans restriction. Ton cadeau finira par être un cadeau empoisonné ou au mieu un déchet.
[^] # Re: Fantastique!
Posté par IsNotGood . En réponse à la dépêche Bitfrost : Un nouveau modèle de sécurité. Évalué à 2.
Ben fais le. Offres (réellement) des OLPC. Je t'y encourage vivement. Ce n'est pas aujourd'hui possible, mais OLPC le prévoit à moyen terme. Ainsi tu pourras acheter 1 ou 2 OLPC et les envoyer à un pays pauvre. Aujourd'hui OLPC est concentré sur les gros clients.
Les OLPC ne sont pas offerts, ils restent la propriété de l'acheteur (gouvernement/ONG/etc). Comme quand ton entreprise achete un PC et installe Linux. C'est la propriétait de l'entreprise et le fait que Linux soit libre, n'implique pas que l'entreprise est obligé de fournir le mot de passe. On peut le regretter que les OLPC ne soit pas offert aux utilisateurs finaux, mais c'est mieux que rien, c'est mieux que des PC conçu à l'origine pour les pays au climat tempéré où il n'y a pas un grain de sable dans l'air.
Imaginons que tu as donnée 1000 OLPC dans une région reculée, à l'accès difficile, sans courrant, sans téléphone, etc...
1 OLPC sur 10 tombe en panne car tel ou tel gus a installé un noyau perso, 1 OLPC sur 10 est volé "avec succès", etc...
Tu fais comment pour réparer les dégâts ? Tu livres les OLPC avec un numéro de téléphone vers un hotline ? Chaque coup de téléphone va couter le prix d'un OLPC...
Tu installes gratuitement Internet dans cette région reculée ? Excellente idée.
> aucune personne tierce ne pourra controler sa machine aussi facilement à distance, ça c'est un fait.
Comment ça contrôler sa machine ?
Pour quoi faire ?
Probablement pour mettre à jour, corriger un petit problème, inhiber la bécane si elle a été volée, etc...
Tu crois que le gouvernement où les ONG n'ont que ça à foutre : surveiller chaque OLPC ?
Et comment est faite la prise de contrôle ?
Sans l'accord de l'utilisateur ?
S'il y a des prises de contrôle sans l'accord de l'utilisateur, elles permettent quoi ?
De lire /home ou seulement de mettre à jour des programmes ?
De tout manière, entre pas de OLPC ou un OLPC contrôlé par l'état, je préfère un OLPC.
Je répète, si tu veux fournir des OLPC contrôlé par personne, n'hésite surtout pas.
[^] # Re: Fantastique!
Posté par IsNotGood . En réponse à la dépêche Bitfrost : Un nouveau modèle de sécurité. Évalué à 2.
Pour que ça marche, il faut que le système d'origine soit en ROM et que toutes modifications arrivent en RAM. C'est bien, mais ça coûte très cher, d'autant que le système d'origine fera dans les 300 Mo voire beaucoup plus (j'ignore combien exactement). Les OLPC ne sont pas destinés a des utilisateurs d'Internet à qui on fournit un système minimum et qui ajoute les programmes qu'ils veulent via le web. OLPC sera livré complet, voire bourré d'information au maximum. Je ne sais pas où ça en est, mais il était prévu d'avoir wikipedia dans OLPC. Pas un navigateur qui se connecte au site wikipedia (la majorité des OLPC n'auront pas de connexion internet), mais wikipedia (une partie du moins) sur l'ordinateur.
Bref, ta solution est très cher. M'enfin, je te félicite d'avoir proposer quelque chose et qu'on puisse en débattre. Vas savoir, ton idée fera peut-être son chemin et il y aura peut-être une version de OLPC, plus cher, mais qui offre la possibilité que tu demande. On pourrait avoir un "double boot". Boot sur la version administrée/contrôlé par l'état et qui doit être rock solide, boot sur une version disponible aux bidouillages les plus fous sans que ça affecte la version "gouvernementale".
Ce qu'il faut comprendre, c'est que les bécane OLPC sont "adminitrées" par le gouvernement/ONG. Si tu veux acheter des OLPC et fournir les clées pour que l'utilisateur puisse tout foutre en l'aire, n'hésites surtout pas.
Je suis convaincu que les gouvernement/ONG commanderons à terme quelques OLPC sans clée, ou avec une clée qu'ils pourront communiquer, pour les hackers en herbe, etc...
T'as un FAI, tu y dépose des informations importantes, tu utilises leur serveur mail, etc... Pourtant tu n'as pas les sources, et le gouvernement peu fouiller tes communications (inutile d'aller dans une dictature pour voir ça, c'est possible en France, il y a les décrets nécessaires).
OLPC est "mis à disposition" comme une entreprise met à disposition un PC pour ses employés, comme un FAI met à disposition un serveur mail, etc...
Si tu n'as pas confiance en ceux qui mettent à disposition OLPC (et pourquoi pas), ben n'utilises pas et achetes toi un OLPC avec les clées ou trouves une personne qui te donne un OLPC avec les clées (il semble qu'ici plein de gens sont disposés à mettre l'argent sur la table pour ça... (rire)).
Si un pays n'autorise que des OLPC sous leur contrôle, là il y a un sérieux problème.
J'aimerai bien être dans un monde idéal, où on peut fournir des OLPC sans protection pour que les utilisateurs puissent se défoncer, etc...
Mais on n'est pas dans un monde idéal. Les populations des pays pauvres le savent très bien.
[^] # Re: ben ça alors !
Posté par IsNotGood . En réponse à la dépêche Bitfrost : Un nouveau modèle de sécurité. Évalué à 3.
Si tu veux acheter des OLPC et les données avec la clée "et tout", n'hésite pas.
Tout le monde t'applaudira des deux mains. Moi compris.
Je suis sûr que la majorité des pays où est destiné OLPC verront ça d'un très bon oeil même si ça met en péril leur "dictature".
Si un pays refuse ton offre, n'hésite pas à nous en informer.
[^] # Re: ben ça alors !
Posté par IsNotGood . En réponse à la dépêche Bitfrost : Un nouveau modèle de sécurité. Évalué à 1.
J'ai dit : "- Tu me fais penser ..."
J'aurai du dire : "- Ton commentaire ..."
> Eh, calme toi un peu l'ami, l'extrémiste ici ce serait plutôt toi ! (en refusant la moindre critique).
C'est facile.
On a un fabuleux projet sans équivalent, et il n'y a que des gus qui critiquent, qui font des fantasmes sur un complot planétaire, etc...
> Ce n'est pas parce que ça a l'air novateur qu'il faut foncer tête baissée sans analyser les possibles dommages collatéraux
Et quel dommages collatéraux ? T'as évaluer les conséquences s'il n'y avait pas OLPC ? Quel serait les dommages collatéraux ?
Ben on laisse la "fracture numérique" et on tourne ses yeux ailleurs... Ah non, on envoie un peu de bouffe, c'est tout ce qu'il mérite.
> et ce n'est pas parce que c'est du linux sous le capot que les utilisateurs seront libérés, eux !
Les libérer de quoi ? De l'emprise de Microsoft ?
Ils n'ont pas Windows ou Mac ou Linux, ni rien.
C'est quoi ton délire ?
Je vais être claire, si MS fait la même chose que OLPC (même fonctionnalité, même possibilité pour les utilisateurs, même coût) mais que le tout en propriétaire, ben j'applaudis des deux mains.
L'enjeux "libérer" est accessoire dans OLPC par rapport aux vrais enjeux.
> mais j'ai avancé des arguments qui effectivement montrent une certaine réserve.
Et mieux que OLPC il y a quoi ? Tu proposes quoi à part des belles intentions ?
C'est comme pour la constitution européen, les donneurs de leçon, ceux qui lavent plus blanc que tout le monde, les biens penseurs qui se prétendent hors de la pensée unique, ont poussé le non car ils avaient mieux ... dans leur fantasme, car ils avaient "des réserves". Au final on a rien.
Prenons les choses positives qui se présentent et avançons au-lieu de tortiller du cul et faire du sur place dans notre merde.
> Mais je ne suis pas parfaitement convaincu par le rapport bénéfice/coût de l'opération par rapport à des méthodes + classiques (profs + cahiers).
La méthode classique, il l'applique aujourd'hui. Et ta méthode classique c'est quoi ? Les laisser là où ils sont ? Que surtout pas ils évoluent ?
> Je ne sais pas si ça sonne "extrême gauche" pour toi, mais je trouve qu'ils manquent déjà de bcp de choses et qu'on ne peut pas se permettre de dilapider des ressources dans un "gadget" !
Dilapider des ressources ?
C'est du délire. On met des ressources pour les gens qui en n'ont le plus besoin et tu parles de "dilapider des ressources"...
Effectivement si dans ton esprit il faut les maintenir dans notre dépendance en n'accordant que de la bouffe au pays pauvres histoire de les maintenir en vit et avoir bonne conscience, effectivement on "dilapide des ressources" par rapport à cet objectif.
Pour toi, c'est un "gadget". Pour moi, ici et maintenant, c'est un "gadget". Pour ceux qui n'ont pas de calculatrice, qui n'ont pas de courrant, qui n'ont rien, ce n'est pas un "gadget".
> vu que ça aura forcément un coût
Maintenir les pays pauvre dans leur pauvreté, ne pas leur donner les moyens d'augmenter le niveau de leur connaissant, ne pas leur donner d'outils, ne pas les inciter à utiliser l'informatique en proposant un produit adapté à leur environnement, ça a un coût. Et ce coût ne s'exprime pas en monnaie sonnante et trébuchante.
Ne t'inquiète pas, OLPC ne va pas augmenter tes impôts. T'auras toujours les moyens d'avoir 2 TV chez toi et de nourrir ton chat avec des boites "Gourmet" 5 étoiles.
Critiquer le "produit" OLPC est compréhensible. L'écran est peut-être trop petit, la manivelle trop fragile, l'autonomie faible, etc... Les développeurs de OLPC le font tous les jours, et tous les jours ils essaient d'améliorer le produit OLPC au-lieu de rester le cul sur une chaise en attendant qu'un solution parfaite, sans "effets collatéraux", tombe du ciel.
Mais on fait quoi en attendant ? Je sais, on envoie de la bouffe. Ça nous coûte pas cher, ces pays restent sous notre dépendance et ne viendront jamais nous concurrencer. Beau programme...
Tu veux les libérer du logiciel propriétaires (foutaise), ils faut les libérer des pays riches. Et ça passe avant tout par l'éducation.