> Par exemple, si tu considères la petite barre en bas qui contient le bouton
> "Démarrer", quand je lance une application ou que ça rame un peu, elle ne
> réponds plus... on ne peut pas dire que ce soit génial...
Quand je lance quelque chose qui fait ramer sur mon linux, mon bureau devient moins réactif aussi. Rien d'extraordinaire (à la limite j'ai plutot l'impression que mon Xfree est bien plus sensible à ça que les windows que j'ai vu passer)
> Sinon, les icônes que tu ne peux pas sélectionner sur ton bureau pendant les
> deux premières minutes après le démarrage de ta session,
Ça c'est plutot un reproche à faire à nos distrib. Chez nous chaque chose se lance en série et on n'a la main qu'à la fin. Sous Win il y a du parallèle et on a la main avant que tout soit initialisé.
Pour beaucoup : en développant du logiciel propriétaire ;) (je met aussi dans ce sac les gens de Mysql ou trolltech par exemple car leurs revenus & salaires se basent sur la vente de proprio, si il n'y en a plus il n'y a plus de salaire)
Pour certains : en faisant tout à fait autre chose que du développement ou de l'informatique (sisi)
Pour d'autres : en étant embauchés par une boite qui fait du service (donc pas comme développeur, c'est bien le sujet du journal)
Pour les derniers : en étant embauchés par une boite qui fait du libre ou qui le sponsorise
Ces derniers étant probablement les moins répandus. Par contre si tout devient libre le nombre de développeurs libres n'évoluera pas en conséquence : vu que justement le libre permet la réutilisation et la redistribution gratuitement, il deviendra assez rarement moins cher de faire redévelopper des briques (contrairement à actuellement).
Le problème n'est pas forcément celui du libre ceci dit, c'est surtout celui des gens qui ne concoivent pas de payer pour quelque chose qui ne leur est pas exclusif et qui ne sont pas motivés pour payer d'eux même si ils n'y sont pas obligés. Malheureusement je ne vois pas de solution à ce problème humain.
> Une licence proprio n'est pas restrictive peut-être ?
Merci de ne pas opposer GPL et proprio. Il y a d'autres licences libres possibles.
> L'histoire a montré que tous les bons produits sous Licence BSD finisse par être
> proprio
C'est du FUD, qu'il soit volontaire ou pas. Un produit sous licence BSD *reste* sous licence BSD. Éventuellement une copie en est faite sous d'autres licence, mais ce qui était accessible de manière libre le reste toujours. Il n'y a aucune perte pour la communauté.
> sans le moindre retour à la communauté.
Ceux qui ne veulent pas contribuer ne le feront pas. Ne crois pas que tu vas les forcer en utilisant la GPL, ils vont simplement utiliser autre chose. Au final ça ne changera pas grand chose pour la communauté ça changera quelque chose uniquement pour ceux qui auraient voulu réutiliser de manière non GPL).
> PS : MS adore la BSD et déteste la GPL.
Et ? Si Bill Gates aime les glaces à la fraise il faut vite jeter toutes mes glaces à la fraise ? C'est marrant mais je ne vois pas l'argument ici.
non-free m'est proposé à l'install, je n'ai rien à faire de spécial pour l'installer (ce n'est pas moi qui vais rajouter une source dont je connais l'adresse), ça télécharge des paquets à partir des serveurs debian, fait par les developpeurs debian, avec les outils et l'infrastructure debian ....
Alors peut être que quelqu'un (ou le groupe) a déclaré "non, la distribution c'est X Y et Z, pas non-free", mais en pratique la seule chose qui change c'est le nom du répertoire et le fait que je peux refuser.
Je ne cherche pas à débattre de ce qui est officialisé comme "la distribution" ou pas, je ne m'attache qu'au concret.
Là c'est "mais non ma distrib ne contient que du free, la preuve : je l'ai écrit sur un bout de papier", tout en sachant que au final ça ne change rien.
> pourquoi faudrait-il rendre difficile l'utilisation de non-free ?
Il ne s'agit pas de rendre difficile, moi ça me va très bien. Mais il s'agit de ne pas être hypocrite. Si ce n'est pas dans la distribution alors on le fait marcher comme le reste qui n'est pas dans la distribution (au choix laisser la personne taper la source externe de manière totalement détacher sans lui proposer, ou proposer plein de sources externes à l'install, non-free etant juste une parmis d'autres dispo en miroir sur Debian).
> nous assumons leur utilisation et fournissons une infrastructure
Déjà ils font plus que ça : ils les proposent dans l'installateur, avec les adresses prédéfinies.
Maintenant Debian, contrairement à une boite comme IBM ce n'est justement que de l'infrastructure. Si ils ont les mêmes serveurs, les mêmes développeurs, le même installateur, les mêmes miroir, les mêmes listes de diffusion, les mêmes outils de traque de bug ..... c'est quoi la différence à part la possibilité de refuser d'utiliser non-free ? c'est juste des belles paroles et du papier.
Ce qu'on a l'impression c'est qu'ils y disent "oui c'est nous mais on va dire que c'est pas nous" et quand on en parlent voilà qu'on nous dit "ils ont dit que c'était pas eux"
> Ce n'est pas de l'hypocritie que pensé que Debian doit continué à soutenir non-free
Je pense que pas grand monde reproche à Debian d'accepter temporairement d'avoir du non-free pour mener à bien ses buts. Je pense que la plupart des gens seraient prêt à accepter aussi une Debian sans non-free, c'est un choix.
L'hypocrisie c'est faire du non-free puis dire "nous c'est tout du libre, le non-free c'est pas la distribution Debian".
Ça me fait peur cet argument. Qu'est ce qui empeche une boite de ne fournir que du binaire et d'affirmer qu'ils l'ont fait en assembleur ? Je n'avais jamais pensé à ça mais là j'ai comme une peur
> - Debian-la-distrib ne contient pas non-free (absent des isos, ne profite pas de
> tous les outils, etc.)
Et encore, parce qu'à ma dernière install (qui date un peu je l'avoue) on m'a bien demandé si je voulais du non-free (une simple question) et j'avais juste un miroir à choisir dans une liste. À aucun moment je n'ai vu une séparation mis à part cette question. Ce n'est pas comme si il y avait "sources externes" et que c'est moi qui remplissait une adresse non proposée et qui n'a rien à voir avec les officielles.
Je dirai "Debian-les-cds" ne contient pas non-free, par contre la distrib je ne sais pas ce qu'elle "contient" mais je sais ce qu'elle "intègre", et ça inclu non-free (même si c'est facultatif).
Tuu peux parler de promotion si tu n'aimes pas le terme publicité, ça revient bien au même. Tiens, moi j'ai vu un spot de pub pour la croix rouge, pourtant ce n'est pas une organisation commerciale.
> Chez mdk, peut de temps, chez Debian beaucoup de temps.
Tu parles d'utiliser testing. Tu me rappelle en combien de temps un paquet de unstable peut passer en testing ? à mon souvenir le minimum n'est que de 15j. Je ne vois pas là de quoi faire une distinction fondamentale
> Mais plus sérieusement, chez Debian les problèmes d'upgrade
> arrivent de temps en temps. Chez mdk/rh, les réussites d'upgrade
> arrivent de temps en temps.
Mouais, mis à part les gens ici qui trollent "vive Debian" je n'ai pas vraiment de stats la dessus, et toi non plus je pense.
Sans compter que ce qu'un utilisateur Mdk considère comme "un pbolème" n'est pas forcément la même chose que pour un utilisateur Debian (je ne dis pas que les gens sous mdk sont des neuneux, mais il faut avouer qu'il y a plus de débutants sous mdk que debian à priori)
Bref .. affirmation gratuite.
Uh ? depuis quand "non libre" veut dire "interdit de redistribution" ? Parce que les docs FDL ne sont pas en non-free Debian risque un procès ? faut arrêter, ce n'est pas vrai.
Sans compter que vu que les non-free sont gérés plus ou moins par Debian et sur les miroirs debian, je ne suis pas sûr que le fait de les y mettre protège Debian d'un procès : que ce soit "dans la distribution" ou "à coté".
> chez Debian (en tout cas c'est ce qui m'arrange) c'est que les updates de soft
> se font sans problème en général. Alors que la premiere fois que j'ai essayé
> d'upgrader une mandrake, j'ai fini par réinstaller
Mes upgrades mdk se passent bien (j'ai même une cooker qui roule avec upgrades réguliers), et tu trouveras des gens qui ont eu des pbs avec debian (pour prendre un exemple concret il me semble que pterjan avait rapporté des pbs quand linuxfr avait eu des problèmes lors du déménagement des serveurs et en avait profité pour faire un update).
De ce coté là je pense qu'il n'y a pas de différence réelle entre mdk et debian.
> sans attendre comme un malade ma 10.2 qui corrige les bugs de la 10.1 ...
Oui enfin pour les bugs il y a des mises à jour entre les versions même chez Mdk.
Après c'est comme tout, tu peux aussi prendre cooker chez mdk (c'est vrai qu'il n'y a pas encore de version intermédiaire pour "test", peut être la community ?)
Dans mon entourage je vois des gens sous Debian, à ma connaissance aucun ne l'est "parce que c'est libre". Certains "parce que ça marche", certains "parce que c'est stable", d'autres "parce que c'est communautaires et pas une société", je soupsonne même certains du "parce que ça fait plus warrior", mais les seuls que je vois choisir "parce que ça garanti que les logiciels du coeur sont libre" sont des gens de linuxfr.
> Ils veulent quelque chose qui marche, point.
Ben oui, et pour ça que les docs FDL soient en non-free ou pas n'y change pas grand chose. Par contre le changement va retarder une mise en stable, va potentiellement entrainer quelques problèmes temporaires. Quelqu'un qui veut juste que ça marche verra plutot ce genre de manip/prévisions d'un mauvais oeil.
Euh, c'est pas parce qu'un code n'est pas libre qu'il est interdit ou litigieux (du point de vue légal) de l'utiliser. Faudrait pas tout mélanger non plus.
Si on relègue des docs FDL en non-free ce n'est pas parce que ça peut t'amener devant la justice.
> Les maladies incurables dont tu parles sont justement une conséquence du
> progrès technique. Le cancer était quasi inconnu à l'époque de Platon.
Je reformule : "la connaissance de ces maladies incurables est une conséquence du progrès". Ben oui, avant on ne connaissait pas non plus les microbes, les bactéries et les virus, c'est pas pour ça qu'il n'y avait pas de malades.
> Autre exemple: le vélo. À part quelques améliorations marginales, il a la même
> forme depuis 1885, date à laquelle on lui a adjoint une chaîne.
Ah ? et le vélo-moteur ? la moto ?
Sans compter que le vélo a été plus ou moins dépassé par une autre invention : la voiture. Oui la voiture n'est pas une évolution du vélo, mais c'est justement l'invention qui a du pas mal le mettre au rebus.
Ton exemple est faussé, tu parles d'invention et tu dis que X n'a pas évolué. On a justement fait des inventions : donc des trucs qui ne sont pas des vélos mais qui permettent de se déplacer tout de même : voiture, moto, patins à roulettes, quad, je ne sais quoi encore
Moi c'est le contraire. Etant une boite FR j'avais confiance dans sa désincription mais visiblement ça ne marche pas (ça a plutot l'air d'avoir l'effet inverse).
> Dans le premier cas, les OGM ne sont pas une invention
Quels arguments ? quelle définition d'invention ? on créé quelque chose qui n'existe pas, suite à une R&D non négligeable. Je ne suis pas contre dégager les manips génétique du cadre de brevets, je suis même ouvert à une définition de "invention" ou "innovation" qui les écarte, mais pour l'instant je n'ai pas trouvé cette dernière.
> puisqu'ils sont non seulement inutiles, mais dangereux.
Inutile c'est *vraiment* contestable. Ce qui les rend inutiles c'est vraiment le mode de distribution (plus ou moins stériles et interdiction d'en faire des semis si jamais on le pouvait), mais ils certains ont un rendement bien supérieur et d'autres ont des qualités non négligeables.
Faut pas prendre les cultivateurs pour des idiots, si il y en a qui utilisent ça c'est bien que ce n'est pas inutile.
Quant à dangereux je suis tout à fait prêt à le dire aussi mais c'est un peu une affirmation gratuite pour l'instant. On va dire "potentiellement dangereux". Mais de toute façon je ne vois pas ce que ça vient faire dans la question des brevets.
> Qui pourrait prétendre désormais « innover » dans ce domaine?
Tout le monde (tiens, l'e-book ? le livre cassette ?)
Je pense que du temps des rouleaux tout le monde aurait aussi pensé qu'on était au stade ultime de l'évolution face à l'amélioration depuis la pierre gravée, et ainsi de suite. Croire que ce qu'on a actuellement est le stade ultime c'est être bien prétentieux. Surtout que le livre est loin d'être un modèle d'ergonomie.
Tout ce que je peux t'assurer c'est que de mon coté je suis entièrement de bonne foi sur la rédaction, et que je n'ai l'impression de faire une arnaque. Je pense sérieusement apporter quelque chose d'utile à ceux qui sont la cible du bouquin.
Quand au fait de faire un livre au lieu de contribuer à la doc je pourrai renvoyer ça à tous ceux qui ont un travail au lieu de contribuer bénévolement et gratuitement. Les deux ne s'oppose pas vraiment et j'ai toujours contribuer aux ressources d'aide, même pendant la rédaction du livre.
De toutes façons ce qu'apporte le livre est bien différent de ce qu'apporte la doc en ligne, que ce soit au niveau support ou au niveau contenu : l'un ne remplace pas l'autre. Il ne s'agit pas pour nous de recopier ou refaire l'équivalent de la doc (ça n'aurait aucun intérêt).
Ceci dit je pense qu'on a assez débattu sur un sujet relativement privé qui n'est pas celui de la news. Je reste ouvert par mail si tu le souhaites. Tu pourras copier ici un résumé en fin de discussion si tu le juges utile mais pas la peine de risquer d'entrainer un troll.
> Mais concrètement, par rapport aux scripts existants, quels sont exactement les
> noms (de fonctions, de classes) qui changent ?
Sauf exception tous les noms de fonction restent tels quels. Il ne s'agit pas de chambouler tout PHP. Globalement la plupart sont en "ma_fonction_a_moi()".
Par contre la plupart des interfaces objet prédéfinies seront désormais avec le type "$objet->studyCapsFunction()". Il faut savoir qu'en PHP4 il y a très peu de méthodes objet prédéfinies. Il y avait domxml (qui a disparu au profit d'un DOM standard), et très récement sqlite, mysqli ou tidy. Ce sont ces trois extensions qui ont posé problème. Comme elles sont très récentes on a jugé que ça ne devait pas casser beaucoup de scripts, et qu'au pire un wrapper PEAR pouvait faire la colle entre les anciens noms et les nouveaux.
C'est un changement politique, du coup il y a eu beaucoup de troll .. débat ... mais ça ne devrait pas gêner grand monde en réalité.
J'ai ouie dire que certains ont réussi à compiler les deux en module Apache avec le versionning et en modifiant légèrement les sources. À défaut de pouvoir te donner un lien concret la méthode simple consiste à passer par l'interface CGI sur au moins une des deux versions.
Après c'est juste une histoire d'associer les extensions à tel ou tel programme CGI ou module. Tu peux probablement utiliser .php5 pour les tests PHP, ou te réserver un répertoire spécial ou les associations sont différentes.
Par contre, quand PHP5 sera sorti depuis quelques temps, vu les faibles incompatibilités, je te propose fortement d'essayer de faire évoluer tes scripts (si c'est nécessaire, ce qui n'est même pas sûr) et de tout passer sur PHP5
> Mouarf, je me marre... Ils ont modifié php5 pour permettre la compatibilité avec
> les scripts php4... bravo les ptits gars de chez Zend, je suis ébloui.
> mais y'a vraiment pas de quoi se lancer des fleurs dans un changelog pour ça !
Il parle du changelog de la RC2. Si un truc si important a été touché ça *doit* être dans le changelog, et en première position même, non ?
Il ne s'agit pas d'un panneau de pub mais d'un changelog justement, tous les changements importants doivent y être, même ceux qui tombent sous le sens. À priori celui là plus que les autres.
> autrement dit, faites gaffe aux majuscules/minuscules lorsque vous
> manipule(re)z une extension php orientée objet
Ben non, parce que les méthodes PHP sont case-insensitive. La différence a été faite entre le mode_eclaté et le modeRegroupé, rien à voir avec les majuscules/minuscules.
> Quel progrès !
Je sens le ton moqueur, mais si tu savais quels débats sans fin ça avait entrainé tu le serais peut être moins. Ben oui, parce que ça remet aussi un peu en cause la sacro sainte compatibilité dont tu parles plus haut. Quand on choisi entre cohérence et compatibilité on peut comprendre que le changement n'a rien ni d'anodin ni d'évident.
> Je ne vois pas comment vous pouvez justifier la promotion d'un bouquin de
> référence "PHP5 avancé" (je cite) alors que le développement de php5 n'est
> visiblement pas terminé.
C'est une question personnelle qui n'a rien à voir avec la news mais je vais répondre tout de même. Le développement de PHP5 on le suit depuis le début, les fonctionnalités techniques on les connait, on les a étudié (d'autant qu'elles n'ont rien de monstrueusement originale face à ce qui existe dans les autres langages) et on a mis à jour au gré des modifications (et dieu sait qu'il y en a eu).
PHP5 n'est pas sorti, il est vrai, mais contrairement à d'autres comme Atkinson on a justement attendu les RC et la finalisation de PHP pour boucler le bouquin. La RC2 est sortie, le bouquin n'est pas sous presse, qu'on ne nous accuse pas de vouloir aller trop vite. Le développement est maintenant en phase de correction de bugs et rien de vraiment inattendu ne se passe depuis quelques temps. Il est peu probable que ce qui est rédigé actuellement se voit dépassé sur autre chose qu'un ou deux détails mineurs dûs à une correction de bug obligatoire.
Maintenant il y a une chose qu'on ne peut pas prétendre, c'est donner des retour d'expériences importants sur PHP5 lui-même (je dis "importants" car je fais déjà mes développements sur PHP5 depuis quelques temps, je vois déjà quelques commentaires à faire). Maintenant on n'a jamais prétendu le faire, et le langage PHP5 sortant à cette période, on ne trompera personne sur ce sujet.
Le livre regroupe le domaine technique PHP5 plus les vécus PHP4, rien de plus mais c'est déjà beaucoup.
> Vous n'êtes pas les premiers à vouloir sortir un bouquin sur php5 avant les autres histoire de vendre plus...
Sauf que les gens qui arriveront à la sortie de PHP5 voudront un bouquin pour décrire tout ça et les aider, d'autant que la doc officielle ne sera pas à jour à priori. On a la capacité de le faire correctement, malgré ce que tu crois (ou du moins on le pense sérieusement), on ne devrait pas le faire ?
Tu veux dire qu'il ne faudrait voir aucun bouquin PHP5 sur les étalages avant décembre 2005 et tant pis pour ceux qui veulent faire du PHP5 entre temps ? (le bouquin a mis 18 mois pour être fait, si PHP sort en juin c'est à peu près ca que ça aurait donné comme date). C'est clair qu'un bouquin sur PHP5 sorti dans 2 ans apportera des plus, principalement au niveau vécu et retour d'expériences, mais est-ce une raison pour ne pas en sortir d'autres entre temps ?
Attention, je parle bien d'un bouquin qui n'est pas bouclé avant un stade avancé du freeze, pas de ceux qui sont sorti actuellement (donc qui ont été bouclés il y a un moins ou deux) voire octobre pendant les bétas (sisi, il y en a eu) et qui ne reflettent pas les changements importants survenus depuis.
De toutes façons les gens qui achètent un bouquin à la sortie du logiciel ou dans les 6 mois suivants savent bien qu'il a été rédigé pendant le développement, on ne trompe personne.
> Quelques points du changelog qui ont retenu mon attention de
> développeur, mais apparemment pas la tienne :
Différence d'orientation. Ce que donne Cyril ce sont des modifications qui impactent les gens et leur permettent de voir des choses concrêtes sur ce qui change. Tu donnes des corrections de bug et modifications internes qui n'intéressent probablement que ceux qui jouent déjà avec les versions PHP5 en développement, donc qui liront le changelog en entier de toutes façons.
Ceci dit je suis d'accord que cyril aurait du mettre un lien vers le changelog comple. Si un modéro pouvait le rajouter ça ne ferait pas de mal.
[^] # Re: Vers la philosophie mono la mort dans l ame.
Posté par Éric (site web personnel) . En réponse à la dépêche Mozilla et Gnome, main dans la main ?. Évalué à 2.
> "Démarrer", quand je lance une application ou que ça rame un peu, elle ne
> réponds plus... on ne peut pas dire que ce soit génial...
Quand je lance quelque chose qui fait ramer sur mon linux, mon bureau devient moins réactif aussi. Rien d'extraordinaire (à la limite j'ai plutot l'impression que mon Xfree est bien plus sensible à ça que les windows que j'ai vu passer)
> Sinon, les icônes que tu ne peux pas sélectionner sur ton bureau pendant les
> deux premières minutes après le démarrage de ta session,
Ça c'est plutot un reproche à faire à nos distrib. Chez nous chaque chose se lance en série et on n'a la main qu'à la fin. Sous Win il y a du parallèle et on a la main avant que tout soit initialisé.
[^] # Re: logiciel libre = mort du developpeur ?
Posté par Éric (site web personnel) . En réponse au journal logiciel libre = mort du developpeur ?. Évalué à 1.
Pour certains : en faisant tout à fait autre chose que du développement ou de l'informatique (sisi)
Pour d'autres : en étant embauchés par une boite qui fait du service (donc pas comme développeur, c'est bien le sujet du journal)
Pour les derniers : en étant embauchés par une boite qui fait du libre ou qui le sponsorise
Ces derniers étant probablement les moins répandus. Par contre si tout devient libre le nombre de développeurs libres n'évoluera pas en conséquence : vu que justement le libre permet la réutilisation et la redistribution gratuitement, il deviendra assez rarement moins cher de faire redévelopper des briques (contrairement à actuellement).
Le problème n'est pas forcément celui du libre ceci dit, c'est surtout celui des gens qui ne concoivent pas de payer pour quelque chose qui ne leur est pas exclusif et qui ne sont pas motivés pour payer d'eux même si ils n'y sont pas obligés. Malheureusement je ne vois pas de solution à ce problème humain.
[^] # Re: Modules non GPL et tours de passe-passe
Posté par Éric (site web personnel) . En réponse à la dépêche Modules non GPL et tours de passe-passe. Évalué à 1.
Merci de ne pas opposer GPL et proprio. Il y a d'autres licences libres possibles.
> L'histoire a montré que tous les bons produits sous Licence BSD finisse par être
> proprio
C'est du FUD, qu'il soit volontaire ou pas. Un produit sous licence BSD *reste* sous licence BSD. Éventuellement une copie en est faite sous d'autres licence, mais ce qui était accessible de manière libre le reste toujours. Il n'y a aucune perte pour la communauté.
> sans le moindre retour à la communauté.
Ceux qui ne veulent pas contribuer ne le feront pas. Ne crois pas que tu vas les forcer en utilisant la GPL, ils vont simplement utiliser autre chose. Au final ça ne changera pas grand chose pour la communauté ça changera quelque chose uniquement pour ceux qui auraient voulu réutiliser de manière non GPL).
> PS : MS adore la BSD et déteste la GPL.
Et ? Si Bill Gates aime les glaces à la fraise il faut vite jeter toutes mes glaces à la fraise ? C'est marrant mais je ne vois pas l'argument ici.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 2.
non-free m'est proposé à l'install, je n'ai rien à faire de spécial pour l'installer (ce n'est pas moi qui vais rajouter une source dont je connais l'adresse), ça télécharge des paquets à partir des serveurs debian, fait par les developpeurs debian, avec les outils et l'infrastructure debian ....
Alors peut être que quelqu'un (ou le groupe) a déclaré "non, la distribution c'est X Y et Z, pas non-free", mais en pratique la seule chose qui change c'est le nom du répertoire et le fait que je peux refuser.
Je ne cherche pas à débattre de ce qui est officialisé comme "la distribution" ou pas, je ne m'attache qu'au concret.
Là c'est "mais non ma distrib ne contient que du free, la preuve : je l'ai écrit sur un bout de papier", tout en sachant que au final ça ne change rien.
> pourquoi faudrait-il rendre difficile l'utilisation de non-free ?
Il ne s'agit pas de rendre difficile, moi ça me va très bien. Mais il s'agit de ne pas être hypocrite. Si ce n'est pas dans la distribution alors on le fait marcher comme le reste qui n'est pas dans la distribution (au choix laisser la personne taper la source externe de manière totalement détacher sans lui proposer, ou proposer plein de sources externes à l'install, non-free etant juste une parmis d'autres dispo en miroir sur Debian).
> Debian-les-CD = Debian-la-distrib.
ça c'est juste une histoire de bout de papier.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 1.
Comme les firmware qui sont dans le kernel vanilla ?
Allons, je ne doute pas que ça soit vrai pour certaines choses dans non-free mais ça n'est pas le but de ce changement ci.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 1.
Déjà ils font plus que ça : ils les proposent dans l'installateur, avec les adresses prédéfinies.
Maintenant Debian, contrairement à une boite comme IBM ce n'est justement que de l'infrastructure. Si ils ont les mêmes serveurs, les mêmes développeurs, le même installateur, les mêmes miroir, les mêmes listes de diffusion, les mêmes outils de traque de bug ..... c'est quoi la différence à part la possibilité de refuser d'utiliser non-free ? c'est juste des belles paroles et du papier.
Ce qu'on a l'impression c'est qu'ils y disent "oui c'est nous mais on va dire que c'est pas nous" et quand on en parlent voilà qu'on nous dit "ils ont dit que c'était pas eux"
> Ce n'est pas de l'hypocritie que pensé que Debian doit continué à soutenir non-free
Je pense que pas grand monde reproche à Debian d'accepter temporairement d'avoir du non-free pour mener à bien ses buts. Je pense que la plupart des gens seraient prêt à accepter aussi une Debian sans non-free, c'est un choix.
L'hypocrisie c'est faire du non-free puis dire "nous c'est tout du libre, le non-free c'est pas la distribution Debian".
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 1.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 1.
> tous les outils, etc.)
Et encore, parce qu'à ma dernière install (qui date un peu je l'avoue) on m'a bien demandé si je voulais du non-free (une simple question) et j'avais juste un miroir à choisir dans une liste. À aucun moment je n'ai vu une séparation mis à part cette question. Ce n'est pas comme si il y avait "sources externes" et que c'est moi qui remplissait une adresse non proposée et qui n'a rien à voir avec les officielles.
Je dirai "Debian-les-cds" ne contient pas non-free, par contre la distrib je ne sais pas ce qu'elle "contient" mais je sais ce qu'elle "intègre", et ça inclu non-free (même si c'est facultatif).
[^] # Re: 3...2...1...Troll !
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 2.
[^] # Re: La sortie de la prochaine Debian menacée == :)
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 1.
Tu parles d'utiliser testing. Tu me rappelle en combien de temps un paquet de unstable peut passer en testing ? à mon souvenir le minimum n'est que de 15j. Je ne vois pas là de quoi faire une distinction fondamentale
> Mais plus sérieusement, chez Debian les problèmes d'upgrade
> arrivent de temps en temps. Chez mdk/rh, les réussites d'upgrade
> arrivent de temps en temps.
Mouais, mis à part les gens ici qui trollent "vive Debian" je n'ai pas vraiment de stats la dessus, et toi non plus je pense.
Sans compter que ce qu'un utilisateur Mdk considère comme "un pbolème" n'est pas forcément la même chose que pour un utilisateur Debian (je ne dis pas que les gens sous mdk sont des neuneux, mais il faut avouer qu'il y a plus de débutants sous mdk que debian à priori)
Bref .. affirmation gratuite.
# Re: La sortie de la prochaine Debian menacée ?
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 3.
à quand le kernel dans non-free ?
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 2.
Sans compter que vu que les non-free sont gérés plus ou moins par Debian et sur les miroirs debian, je ne suis pas sûr que le fait de les y mettre protège Debian d'un procès : que ce soit "dans la distribution" ou "à coté".
[^] # Re: La sortie de la prochaine Debian menacée == :)
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à -1.
> se font sans problème en général. Alors que la premiere fois que j'ai essayé
> d'upgrader une mandrake, j'ai fini par réinstaller
Mes upgrades mdk se passent bien (j'ai même une cooker qui roule avec upgrades réguliers), et tu trouveras des gens qui ont eu des pbs avec debian (pour prendre un exemple concret il me semble que pterjan avait rapporté des pbs quand linuxfr avait eu des problèmes lors du déménagement des serveurs et en avait profité pour faire un update).
De ce coté là je pense qu'il n'y a pas de différence réelle entre mdk et debian.
> sans attendre comme un malade ma 10.2 qui corrige les bugs de la 10.1 ...
Oui enfin pour les bugs il y a des mises à jour entre les versions même chez Mdk.
Après c'est comme tout, tu peux aussi prendre cooker chez mdk (c'est vrai qu'il n'y a pas encore de version intermédiaire pour "test", peut être la community ?)
[^] # Re: La sortie de la prochaine Debian menacée == :)
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 5.
> Ils veulent quelque chose qui marche, point.
Ben oui, et pour ça que les docs FDL soient en non-free ou pas n'y change pas grand chose. Par contre le changement va retarder une mise en stable, va potentiellement entrainer quelques problèmes temporaires. Quelqu'un qui veut juste que ça marche verra plutot ce genre de manip/prévisions d'un mauvais oeil.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Éric (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 2.
Si on relègue des docs FDL en non-free ce n'est pas parce que ça peut t'amener devant la justice.
[^] # Re: Le format JPEG sous le coup d'un brevet
Posté par Éric (site web personnel) . En réponse à la dépêche Le format JPEG sous le coup d'un brevet. Évalué à 1.
> progrès technique. Le cancer était quasi inconnu à l'époque de Platon.
Je reformule : "la connaissance de ces maladies incurables est une conséquence du progrès". Ben oui, avant on ne connaissait pas non plus les microbes, les bactéries et les virus, c'est pas pour ça qu'il n'y avait pas de malades.
> Autre exemple: le vélo. À part quelques améliorations marginales, il a la même
> forme depuis 1885, date à laquelle on lui a adjoint une chaîne.
Ah ? et le vélo-moteur ? la moto ?
Sans compter que le vélo a été plus ou moins dépassé par une autre invention : la voiture. Oui la voiture n'est pas une évolution du vélo, mais c'est justement l'invention qui a du pas mal le mettre au rebus.
Ton exemple est faussé, tu parles d'invention et tu dis que X n'a pas évolué. On a justement fait des inventions : donc des trucs qui ne sont pas des vélos mais qui permettent de se déplacer tout de même : voiture, moto, patins à roulettes, quad, je ne sais quoi encore
[^] # Re: Je filtre mes mails avec
Posté par Éric (site web personnel) . En réponse au sondage Je filtre mes mails avec. Évalué à 2.
[^] # Re: Le format JPEG sous le coup d'un brevet
Posté par Éric (site web personnel) . En réponse à la dépêche Le format JPEG sous le coup d'un brevet. Évalué à 2.
Quels arguments ? quelle définition d'invention ? on créé quelque chose qui n'existe pas, suite à une R&D non négligeable. Je ne suis pas contre dégager les manips génétique du cadre de brevets, je suis même ouvert à une définition de "invention" ou "innovation" qui les écarte, mais pour l'instant je n'ai pas trouvé cette dernière.
> puisqu'ils sont non seulement inutiles, mais dangereux.
Inutile c'est *vraiment* contestable. Ce qui les rend inutiles c'est vraiment le mode de distribution (plus ou moins stériles et interdiction d'en faire des semis si jamais on le pouvait), mais ils certains ont un rendement bien supérieur et d'autres ont des qualités non négligeables.
Faut pas prendre les cultivateurs pour des idiots, si il y en a qui utilisent ça c'est bien que ce n'est pas inutile.
Quant à dangereux je suis tout à fait prêt à le dire aussi mais c'est un peu une affirmation gratuite pour l'instant. On va dire "potentiellement dangereux". Mais de toute façon je ne vois pas ce que ça vient faire dans la question des brevets.
> Qui pourrait prétendre désormais « innover » dans ce domaine?
Tout le monde (tiens, l'e-book ? le livre cassette ?)
Je pense que du temps des rouleaux tout le monde aurait aussi pensé qu'on était au stade ultime de l'évolution face à l'amélioration depuis la pierre gravée, et ainsi de suite. Croire que ce qu'on a actuellement est le stade ultime c'est être bien prétentieux. Surtout que le livre est loin d'être un modèle d'ergonomie.
[^] # Re: Le format JPEG sous le coup d'un brevet
Posté par Éric (site web personnel) . En réponse à la dépêche Le format JPEG sous le coup d'un brevet. Évalué à 1.
[^] # Re: Les spécifications du langage D sont arrivées
Posté par Éric (site web personnel) . En réponse à la dépêche Les spécifications du langage D sont arrivées. Évalué à 3.
[^] # Re: La seconde release candidate de PHP 5 est sortie
Posté par Éric (site web personnel) . En réponse à la dépêche La seconde release candidate de PHP 5 est sortie. Évalué à 1.
Quand au fait de faire un livre au lieu de contribuer à la doc je pourrai renvoyer ça à tous ceux qui ont un travail au lieu de contribuer bénévolement et gratuitement. Les deux ne s'oppose pas vraiment et j'ai toujours contribuer aux ressources d'aide, même pendant la rédaction du livre.
De toutes façons ce qu'apporte le livre est bien différent de ce qu'apporte la doc en ligne, que ce soit au niveau support ou au niveau contenu : l'un ne remplace pas l'autre. Il ne s'agit pas pour nous de recopier ou refaire l'équivalent de la doc (ça n'aurait aucun intérêt).
Ceci dit je pense qu'on a assez débattu sur un sujet relativement privé qui n'est pas celui de la news. Je reste ouvert par mail si tu le souhaites. Tu pourras copier ici un résumé en fin de discussion si tu le juges utile mais pas la peine de risquer d'entrainer un troll.
[^] # Re: La seconde release candidate de PHP 5 est sortie
Posté par Éric (site web personnel) . En réponse à la dépêche La seconde release candidate de PHP 5 est sortie. Évalué à 2.
> noms (de fonctions, de classes) qui changent ?
Sauf exception tous les noms de fonction restent tels quels. Il ne s'agit pas de chambouler tout PHP. Globalement la plupart sont en "ma_fonction_a_moi()".
Par contre la plupart des interfaces objet prédéfinies seront désormais avec le type "$objet->studyCapsFunction()". Il faut savoir qu'en PHP4 il y a très peu de méthodes objet prédéfinies. Il y avait domxml (qui a disparu au profit d'un DOM standard), et très récement sqlite, mysqli ou tidy. Ce sont ces trois extensions qui ont posé problème. Comme elles sont très récentes on a jugé que ça ne devait pas casser beaucoup de scripts, et qu'au pire un wrapper PEAR pouvait faire la colle entre les anciens noms et les nouveaux.
C'est un changement politique, du coup il y a eu beaucoup de troll .. débat ... mais ça ne devrait pas gêner grand monde en réalité.
[^] # Re: Cache Firebird
Posté par Éric (site web personnel) . En réponse au journal Cache Firebird. Évalué à 1.
[^] # Re: La seconde release candidate de PHP 5 est sortie
Posté par Éric (site web personnel) . En réponse à la dépêche La seconde release candidate de PHP 5 est sortie. Évalué à 2.
Après c'est juste une histoire d'associer les extensions à tel ou tel programme CGI ou module. Tu peux probablement utiliser .php5 pour les tests PHP, ou te réserver un répertoire spécial ou les associations sont différentes.
Par contre, quand PHP5 sera sorti depuis quelques temps, vu les faibles incompatibilités, je te propose fortement d'essayer de faire évoluer tes scripts (si c'est nécessaire, ce qui n'est même pas sûr) et de tout passer sur PHP5
[^] # Re: La seconde release candidate de PHP 5 est sortie
Posté par Éric (site web personnel) . En réponse à la dépêche La seconde release candidate de PHP 5 est sortie. Évalué à 3.
> les scripts php4... bravo les ptits gars de chez Zend, je suis ébloui.
> mais y'a vraiment pas de quoi se lancer des fleurs dans un changelog pour ça !
Il parle du changelog de la RC2. Si un truc si important a été touché ça *doit* être dans le changelog, et en première position même, non ?
Il ne s'agit pas d'un panneau de pub mais d'un changelog justement, tous les changements importants doivent y être, même ceux qui tombent sous le sens. À priori celui là plus que les autres.
> autrement dit, faites gaffe aux majuscules/minuscules lorsque vous
> manipule(re)z une extension php orientée objet
Ben non, parce que les méthodes PHP sont case-insensitive. La différence a été faite entre le mode_eclaté et le modeRegroupé, rien à voir avec les majuscules/minuscules.
> Quel progrès !
Je sens le ton moqueur, mais si tu savais quels débats sans fin ça avait entrainé tu le serais peut être moins. Ben oui, parce que ça remet aussi un peu en cause la sacro sainte compatibilité dont tu parles plus haut. Quand on choisi entre cohérence et compatibilité on peut comprendre que le changement n'a rien ni d'anodin ni d'évident.
> Je ne vois pas comment vous pouvez justifier la promotion d'un bouquin de
> référence "PHP5 avancé" (je cite) alors que le développement de php5 n'est
> visiblement pas terminé.
C'est une question personnelle qui n'a rien à voir avec la news mais je vais répondre tout de même. Le développement de PHP5 on le suit depuis le début, les fonctionnalités techniques on les connait, on les a étudié (d'autant qu'elles n'ont rien de monstrueusement originale face à ce qui existe dans les autres langages) et on a mis à jour au gré des modifications (et dieu sait qu'il y en a eu).
PHP5 n'est pas sorti, il est vrai, mais contrairement à d'autres comme Atkinson on a justement attendu les RC et la finalisation de PHP pour boucler le bouquin. La RC2 est sortie, le bouquin n'est pas sous presse, qu'on ne nous accuse pas de vouloir aller trop vite. Le développement est maintenant en phase de correction de bugs et rien de vraiment inattendu ne se passe depuis quelques temps. Il est peu probable que ce qui est rédigé actuellement se voit dépassé sur autre chose qu'un ou deux détails mineurs dûs à une correction de bug obligatoire.
Maintenant il y a une chose qu'on ne peut pas prétendre, c'est donner des retour d'expériences importants sur PHP5 lui-même (je dis "importants" car je fais déjà mes développements sur PHP5 depuis quelques temps, je vois déjà quelques commentaires à faire). Maintenant on n'a jamais prétendu le faire, et le langage PHP5 sortant à cette période, on ne trompera personne sur ce sujet.
Le livre regroupe le domaine technique PHP5 plus les vécus PHP4, rien de plus mais c'est déjà beaucoup.
> Vous n'êtes pas les premiers à vouloir sortir un bouquin sur php5 avant les autres histoire de vendre plus...
Sauf que les gens qui arriveront à la sortie de PHP5 voudront un bouquin pour décrire tout ça et les aider, d'autant que la doc officielle ne sera pas à jour à priori. On a la capacité de le faire correctement, malgré ce que tu crois (ou du moins on le pense sérieusement), on ne devrait pas le faire ?
Tu veux dire qu'il ne faudrait voir aucun bouquin PHP5 sur les étalages avant décembre 2005 et tant pis pour ceux qui veulent faire du PHP5 entre temps ? (le bouquin a mis 18 mois pour être fait, si PHP sort en juin c'est à peu près ca que ça aurait donné comme date). C'est clair qu'un bouquin sur PHP5 sorti dans 2 ans apportera des plus, principalement au niveau vécu et retour d'expériences, mais est-ce une raison pour ne pas en sortir d'autres entre temps ?
Attention, je parle bien d'un bouquin qui n'est pas bouclé avant un stade avancé du freeze, pas de ceux qui sont sorti actuellement (donc qui ont été bouclés il y a un moins ou deux) voire octobre pendant les bétas (sisi, il y en a eu) et qui ne reflettent pas les changements importants survenus depuis.
De toutes façons les gens qui achètent un bouquin à la sortie du logiciel ou dans les 6 mois suivants savent bien qu'il a été rédigé pendant le développement, on ne trompe personne.
> Quelques points du changelog qui ont retenu mon attention de
> développeur, mais apparemment pas la tienne :
Différence d'orientation. Ce que donne Cyril ce sont des modifications qui impactent les gens et leur permettent de voir des choses concrêtes sur ce qui change. Tu donnes des corrections de bug et modifications internes qui n'intéressent probablement que ceux qui jouent déjà avec les versions PHP5 en développement, donc qui liront le changelog en entier de toutes façons.
Ceci dit je suis d'accord que cyril aurait du mettre un lien vers le changelog comple. Si un modéro pouvait le rajouter ça ne ferait pas de mal.