Sans faire de remarque désobligeante, parce que ça ne sert à rien, je trouve aussi que le simple-clic c'est vachement mieux.
Question d'habitude, on s'y fait assez vite, et quand il faut double-cliquer maintenant, ça m'énerve ^^
Peut-être, si c'est possible, avoir un moyen simple et rapide de changer le comportement ?
Ouais, ça sera mieux connu, donc plus facile d'exploiter les failles.
Pas moins sécurisé, mais plus aisé d'accès...
Mais ce problème reste plus large, non ? Je veux dire, si une boîte veut assurer la sécurité de son appli, et réagir à toutes les failles trouvées, elle doit entretenir des développeurs pour faire ce travail ?
Ces développeurs peuvent migrer l'appli en PHP5, finalement c'est aussi une correction de failles multiples, non ?
Et si la boîte ne veut pas avoir de devs qui se chargent du bidule, c'est qu'implicitement elle accepte le risque que des failles soient trouvées, mais qu'il sera bien temps de réagir à ce moment là, d'ici là il y a le fameux : « ça marche, on ne touche pas. »
Et si on ne touche pas parce que ça marche, on ne touche à rien, on conserve le serveur sans rien changer, le même apache, le même PHP4, et tout fonctionne comme avant.
En gros l'entreprise elle a deux alternatives : focaliser sur lasécurité et toujours tout mettre à jour, patcher, et corriger. Je pense que là la migration PHP4->PHP5 rentre dans la politique de sécurité, ça fait juste un patch de plus, à mon avis pas extrêmement complexe à faire.
Ou alors se dire « ça fonctionne on ne touche à rien », et là, que le PHP4 soit ou non encore supporté n'a aucune importance : quand on ne touche à rien, on ne touche à rien...
Me trompé-je ?
Y'a-t-il vraiment un cas pratique où l'arrêt du support de PHP4 va réellement causer des problèmes ?
Le « trou » existe déjà, il peut déjà être exploité, garder strictement la même configuration ne rend pas avec le temps ton appli mon sécurisée.
Le trou, il est là, ou il n'est pas là, c'est quand même assez binaire...
Ce n'est pas parce qu'une faille est découverte six mois après la sortie d'un logiciel, qu'elle n'était pas déjà présente au début.
"Ca ne sera pas moins sécurisé qu'aujourd'hui" dépend strictement de comment c'est aujourd'hui.
* Ca ne sera pas moins sécurisé qu'aujourd'hui.
* Si tu as des gens pour faire des audits de sécurité, et coder des patchs pour tes applis, alors tu as des gens pour les migrer en PHP5 pour raisons de sécurité. Ce n'est qu'un patch de plus, pas forcément plus difficile à faire qu'un autre (ça reste globalement pareil PHP).
* Si tu ne développes pas l'appli toi-même, mais que tu te contentes de la maintenir à jour, pour raisons de sécurité, c'est elle qui passera à PHP5, pour raisons de sécurité.
Le seul argument qu'il te reste sont les patchs de sécurité PHP4.
Qui sont encore maintenus pour pas mal de temps, un an.
Ca laisse le temps de trouver une solution, si c'est vraiment critique, non ?
Et les problèmes de sécurité de PHP4 sont justement une des raisons de l'existence de PHP5. Donc, si c'est vraiment critique, alors, tu fais l'effort de migrer, non ? Et si ça ne l'est pas et que comme la plupart des gens tu as un PHP4 pas super à jour avec les tout derniers patchs, ça ne changera pas grand chose...
Oui, mais, il n'y a que le support PHP4 qui est arrêté.
Le service LAMP avec PHP4 et tout un tas d'applis PHP4 dessus, il suffit de le laisser en place, et tout va continuer à fonctionner. Les sources sont (et seront) toujours disponibles. On pourra encore installer un PHP4 dans dix ans, même s'il faudra un Apache 2.2 maxi par exemple, il sera aussi disponible...
Les gens ne sont pas *obligés* de migrer !
surtout s'il s'agit d'un serveur entièrement géré par une entreprise et qu'elle n'a rien à demander à qui que ce soit.
L'idée là c'est plus que les services d'hébergements de pages web, sont incités à passer à PHP5. Dessus il y a majoritairement (j'insiste sur ce mot) des sites persos. Donc des forums, blogs, et cie, qui souvent vont très bien fonctionner en PHP5, pour peu éventuellement qu'une mise à jour soit faite.
En fait, je doute que cette annonce change vraiment grand chose pour les entreprises...
Je peux me tromper.
Ouhlà, prend pas mes propos pour parole d'évangile au sujet du PHP, moi je dev en Python sur le grand nain ternète. Et si j'ai du PHP à faire, il doit probablement être compatible PHP1 à PHP5 tellement je ne fais pas des choses complexes...
Je n'ai *aucune* idée de la réalité, et de l'importance, de cette incompatibilité entre PHP4 et PHP5. Globalement, ça marche pareil. Si on n'a pas de dev sous la main et que ça ne marche pas pareil, on peut bidouiller assez aisément avec apache pour avoir les deux.
Et je pense que dans la majeure partie des cas, il n'y a certes aucun besoin de passer de PHP4 à PHP5, mais aussi aucune difficulté, et que ça marche tout seul...
Alors je dis juste qu'il faut relativiser le problème, je ne crois pas qu'il y ait quoi que ce soit de dramatique...
D'un point de vue personnel, je n'aime pas le PHP, s'il est capable d'évoluer et de se débarrasser de ses défauts, je réviserait peut-être mon jugement, donc j'accueille la nouvelle plutôt bien !
Yth, qui retourne à son python, parce que le python, c'est bon !
Bah, avec PHP ça marchera toujours : si t'as *vraiment* besoin de faire tourner un truc en PHP4 et pas PHP5, ben suffit d'installer PHP4, qui sera toujours disponible, même si plus maintenu.
C'est même possible de faire cohabiter les deux dans un même apache. Là par contre tu auras peut-être intérêt à renommer tes fichiers .php qui doivent tourner en PHP4, en fichiers .php4 (et les liens internes aussi), mais c'est un assez moindre effort. Et pas besoin de regarder comment marche l'appli.
Ou alors de configurer apache pour lui dire que dans tel répertoire les fichiers .php sont à envoyer au module PHP4, et là, ya plus rien à changer à ton appli.
Bref, pour répondre au tout premier message, ça semble plus une bonne qu'une mauvaise idée. C'est aussi ça la force du libre : on n'est pas *obligé* de se traîner les boulets des erreurs de jeunesse des logiciels. On le voit bien avec le noyau Linux, il bouge énormément, cassant allègrement des vieilles compatibilités, au final on y gagne bien plus qu'on y perd.
Gnagnagna, c'pas fermé, et dans « la liberté et l'échange », il y a « l'échange », et on a *aussi* le droit d'échanger des bons mots, et des conseils en orthographe française.
Le partage de connaissance, c'pas *que* pour résoudre les problèmes de conf de sendmail môssieur Ronchon !
Les critiques, c'est bien, ça fait progresser, si tout le monde te dit tout le temps que t'es génial quand tu fais des conneries, t'es pas prêt de t'améliorer.
Alors la prochaine fois t'écriras « c'est » et non « c », si tu as un minimum de respect pour les gros lourds, chiants, désagréables, et imbus d'eux-mêmes, comme moi, qui vont te lire. Parce que c'est juste du respect môssieur Ronchon. Parce qu'on peut ronchonner en étant respectueux des gens môssieur Ronchon !
Et surtout, sur ce site, il n'y a pas un « vous » qui regroupe les gens du site par opposition aux simples visiteurs. Les admins ils sont quatre pelés (bon, un peu plus), et c'pas forcément les plus bavards. Dans ce « vous êtes de plus en plus lourd », il y a toi, le gros lourd qui vient pour la énième milliardième fois encore inlassablement et tout aussi inutilement, te plaindre qu'il y a des gens qui sont lourds.
Putain, t'es vraiment lourd, mais quand est-ce qu'on pourra enfin, tranquillement, faire un petit message court, avec une note d'humour, informant juste des quelques fautes de français commises dans un journal ou une dépêche, sans qu'un gros lourd vienne avec ses gros sabots de gros lourd derrière dire « Aaaah, y'en a mare D gro lour ki fé D rmq sur le fôtes ! », fais chier !
Je revendique mon droit à corriger, aimablement, simplement, efficacement, et si possible humoristiquement, les erreurs de français commises par d'autres, sans avoir à me coltiner des gros lourds qui vont me répondre en langage SMS que je suis un gros lourd !
Je soutiens totalement Chrisix sur ce coup-là. En plus, c'était drôle.
Mais forcément un bon mot basé sur la subtilité d'écriture de deux mots qui se prononcent pareil mais ont des sens différents, ça ne peut se comprendre que si on fait des efforts pour bien écrire. Fais-les ces efforts, tu crèveras moins bête, en plus tu rigoleras à la lecture du message précédent, plutôt que de casser les couilles de tout le monde avec ton message aigri de gros lourd.
Ben tu lui dis de pas le faire !
Quelle question...
Et oui, c'est possible de *ne pas* mettre à jour un paquet sous slack.
C'est même possible d'avoir en parallèle deux versions d'un même paquet ! Pour le cas où ça pourrait servir (ça m'est arrivé).
Ca t'en bouche un coin ?
Mais personne ne vénère Pat !
T'adores faire de la provoc' hein ?
Il existe des outils permettant de savoir si le système est complet et s'ils ne manque pas de dépendances, et si oui, où elles manquent, et quelles elles sont.
Les choses se font différemment d'ailleurs, mais on peut faire les mêmes.
Et qu'est-ce que c'est que cette histoire de « les laisser penser qu'ils maîtrisent » ? Insultant maintenant en plus ? Les utilisateurs de la slack croient tout savoir mais sont des débiles ?
Ah ben charmant, vraiment, t'as le don pour te rendre sympathique toi...
Ben tu me rappelleras quand tu auras vraiment quelque chose à dire.
Cracher c'est fun, mais ça ne mène à rien tu sais.
Rhalalala, monsieur ne lit que ce qu'il veut lire.
Monsieur dit qu'il ne veut pas troller, et pourtant...
« si tu installe tous tes soft à la mains »
Et non !
C'est juste faux, la slack est très complète, et les logiciels que tu rajoutes sont purement et simplement des choix que tu fais différemment de ceux de Patrick, par exemple j'utilise windowmaker avec rox, et sylpheed, mais je pourrais utiliser xfce ou kde, avec thunderbird.
Dingue ça, trois paquets à ajouter, vraiment du délire...
Allez, j'ai aussi ajouté mplayer, graveman et psi.
Il y avait xine, xcdroast et pidgin.
Et je n'en ai compilé aucun, il y a des dépôts avec ce travail déjà effectué...
Pour tout le reste c'est là, tout les serveurs que tu veux, apache, php, python, ruby, perl, sendmail, proftpd, vsftpd, bind, dhcpcd, dnsmasq, que sais-je encore... des paquets, il y en a environ 900, et les logiciels ne sont pas découpés en truc-data, truc-devel, truc-lib, truc-main, donc ça correspond à beaucoup plus dans d'autres distribs.
« Dans toutes les distribs normales, tu es libre de pouvoir installer ce que tu veux comme tu veux, sans aucune contrainte (si si, même sous *untu ou m4ndr1v4 !), mais comme tu le souligne, tu romps avec ta distribution, ce qui n'est pas sans inconvénients. »
Et là, sous slack, tu ne romps *pas* avec ta distrib, faire un paquet est trivial, avec les pkgtool ou avec checkinstall, ton nouveau logiciel que tu as compilé toi-même s'intègre à ta distrib immédiatement, tu es libre de faire comme bon te semble et ceci en accord avec ta distrib.
Si ta liberté c'est celle de tout casser et de ne plus pouvoir profiter des outils de mise à jour et de la gestion des paquets, autant utiliser une LFS, je te retourne la question : quel intérêt alors d'utiliser une Debian, une Fedora, une Mandriva ?
Toi t'as juste envie de casser du bois sur le dos de la Slack, tu ne comprends pas son intérêt, ou qu'on puisse l'apprécier, laisse au moins ceux qui eux voient cet intérêt et apprécient cette distrib en paix, t'es pas prêt de me voir cracher sur Debian en disant qu'elle n'apporte rien. Mais moi, personnellement, je ne me sens pas à l'aise, même avec une Debian, elle m'étouffe.
Ma slack ne fait pas rien, je suis en slackware-current, mise à jour très régulièrement, toujours stable, toujours robuste, et ça n'entre pas en conflit avec ce que j'ajoute moi-même pour la personnaliser. Ma Slack c'est la mienne, unique, mais c'est aussi une Slackware 12.0 complète. Je n'ai pas fait de réinstallation complète, et mon vieux paquet dosemu-1.3.4 compilé à la mimine fonctionne toujours aussi bien, et je vais faire un beau paquet dosemu-1.4.0, qui est sorti il y a peu, et je dirais upgradepkg dosemu-1.4.0, il fera la mise à jour, et ça continuera à très bien marcher, et je continuerai d'avoir une Slackware 12.0, puis à nouveau une slackware-current, avec *mes* touches personnelles...
Pendant ce temps là, Xorg est mis à jour, KDE aussi, firefox, apache, python, et je ne fais rien à la main.
Alors dire que la Slackware est une distrib qui ne fait rien, c'est manquer singulièrement de flemme et de paresse, deux grande qualités de l'informaticien.
Ben si, c'est un intérêt.
Un intérêt dépendant de comment tu veux, ou aime, faire les choses.
Ce n'est pas un intérêt pour une distrib avec l'objectif d'une mandriva ou d'une ubuntu, à volonté d'être très aisément utilisable par un néophyte (quel que puisse être leur degré de réussite dans ce domaine).
C'est un gros intérêt quand ce que tu recherches est un cadre solide, une base en acier, sur laquelle tu peux construire ce que tu veux, comme tu le veux, et sans aucune contrainte.
Parce que la slack ne t'impose rien, du tout, elle pose le nécessaire à faire fonctionner un système GNU/Linux complet, et à jour, simplement et efficacement. Après tu es libre, tu fais comme bon te semble et jamais ta slack ne se mettra sur ton chemin.
Ce qui est faux avec la très grande majorité des autres distribs, essentiellement celles qui ont des gestions de dépendances.
Tu essaieras avec une Debian de bricoler sur un paquet donné, et de casser tes dépendances, dpkg te dit que tel paquet pose problème, qu'il faut que tu le résolves. Et là tu te dis « ok, c'est complexe, pas le temps dans les cinq minutes, je verrai plus tard ». Ben tu peux pas, parce que la prochaine fois que tu voudras installer ou modifier un paquet quelconque, n'ayant *aucun* rapport avec ton paquet à problème, il te dira que ta Debian est cassée et qu'il *faut* que tu résolves ton problème avant. Et ça, c'est parfois extrêmement chiant, et quand tu es confronté à ce genre de situation ; parce que tu veux faire certaines choses comme tu veux les faire, et non comme ta distrib te dis qu'il faut les faire, et qu'elle t'en empêche.
D'où oui, c'est vraiment un intérêt. Pas pour tout le monde, par pour toutes les utilisations, mais un intérêt réel.
Et non, la slack n'est pas simplement un live-cd d'installation et un serveur ftp, c'est une distrib solide, stable, et fiable. Tu sais que si tu l'installes tu auras ta base, ton cadre connu et maîtrisé. C'est juste un gain de temps et d'efforts phénoménal, avec la liberté totale.
(Et je n'ai *jamais* dis que la Slack était un cas unique, et qu'aucune autre distrib pouvait rendre le même genre de service, merci de ne pas me faire dire ce que je n'ai pas dis, je prend les devants.)
Ah, flûte, c'est quand même super bien checkinstall.
Bon, tant pis, nul doute que ça s'arrangera rapidement.
Allez, slackpkg update, slackpkg install-new, slackpkg upgrade-all !
bien sûr, un IDE va comprendre ce que ton code fait, en analysant avec son cerveau positronique, et faire un cours avec présentation sur vidéo-projecteur pour le prochain développeur à se pencher sur chacun de tes bouts de code.
Il répondra même aux questions. En soixante-sept langues, trente-quatre dialectes, quarante-sept idiomes, et deux-cent-trente-huit variantes locales ou argotiques.
Mon code est toujours assez fortement commenté, que ce soit pour moi, ou pour le boulot.
J'ai même tendance à mieux commenter encore quand c'est pour moi, parce que j'ai le temps, pas de deadline pourrie et de trucs à rendre vite fait mal fait pour avant-hier.
Boah, tout les gens de mon entourage qui ont voté Sarko, y'en a pas beaucoup quand même, l'ont fait pour de mauvaises raisons, pour des choses qu'il a dit et qu'il aurait intérêt à ne pas faire, ce qu'il fera probablement (ne pas le faire).
En tout cas, les commentaires sur le site de libération sont unanimement opposés à cet illustre inconnu parmi tant d'autres, qui n'a pas l'air particulièrement ouvert d'esprit sur autre chose que le profit rapide, au vu de l'article...
Dans « performances » :
Mode de TCL : Utiliser le TCL matériel pour le premier niveau de pipeline.
A la place du défaut : Court-circuiter le pipeline TCL par une machine à états qui génère le code TCL à la volée.
J'ai aussi augmenté la « Size of command buffer (in kb) » de 8 à 32
Et j'ai aussi désactivé le « low-impact fallback ».
Je n'ai *aucune* idée de ce que tout ceci peut bien signifier ^^
En gros j'ai essayé de changer des trucs pour voir ce que ça donne, à première vue ça a des effets, en l'occurrence positifs.
Je ne dis pas que c'est la seule à posséder cette immense qualité, mais la Slackware ne se met *vraiment* pas en travers de ton chemin, c'est une base fiable et solide, sur laquelle tu peux apprendre et construire le système que tu veux.
Alors oui, elle s'adresse plus à des gens qui veulent farfouiller dans la tripaille, et vraiment comprendre, et pas tellement à des gens qui ne veulent qu'être utilisateurs et avoir un système qui marche sans faire d'effort. Mais ces gens existent, la preuve ! (Non, non, je ne suis pas une émanation du réseau).
De plus, sachant que les logiciels sont les mêmes partout d'une distrib à l'autre, la Slackware, pourquoi pas ?
J'ai le même firefox, le même blender, le même sylpheed, le même psi, le même kde/windowmaker/xfce... (pas gnome :p), le même audacity, le même mplayer, et j'en passe, que sur n'importe quelle autre distribution.
[^] # Re: sympa mais manque de coherence dans l'aspect general
Posté par Yth (Mastodon) . En réponse au journal Toutou linux 02-17 est sortie. Évalué à 3.
Question d'habitude, on s'y fait assez vite, et quand il faut double-cliquer maintenant, ça m'énerve ^^
Peut-être, si c'est possible, avoir un moyen simple et rapide de changer le comportement ?
Yth.
[^] # Re: Merci...
Posté par Yth (Mastodon) . En réponse au journal SlackE17 est juillet \o/. Évalué à 4.
Merci Jérôme :)
Yth, slacker depuis le millénaire dernier.
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 2.
Pas moins sécurisé, mais plus aisé d'accès...
Mais ce problème reste plus large, non ? Je veux dire, si une boîte veut assurer la sécurité de son appli, et réagir à toutes les failles trouvées, elle doit entretenir des développeurs pour faire ce travail ?
Ces développeurs peuvent migrer l'appli en PHP5, finalement c'est aussi une correction de failles multiples, non ?
Et si la boîte ne veut pas avoir de devs qui se chargent du bidule, c'est qu'implicitement elle accepte le risque que des failles soient trouvées, mais qu'il sera bien temps de réagir à ce moment là, d'ici là il y a le fameux : « ça marche, on ne touche pas. »
Et si on ne touche pas parce que ça marche, on ne touche à rien, on conserve le serveur sans rien changer, le même apache, le même PHP4, et tout fonctionne comme avant.
En gros l'entreprise elle a deux alternatives : focaliser sur lasécurité et toujours tout mettre à jour, patcher, et corriger. Je pense que là la migration PHP4->PHP5 rentre dans la politique de sécurité, ça fait juste un patch de plus, à mon avis pas extrêmement complexe à faire.
Ou alors se dire « ça fonctionne on ne touche à rien », et là, que le PHP4 soit ou non encore supporté n'a aucune importance : quand on ne touche à rien, on ne touche à rien...
Me trompé-je ?
Y'a-t-il vraiment un cas pratique où l'arrêt du support de PHP4 va réellement causer des problèmes ?
Yth...
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 1.
Le trou, il est là, ou il n'est pas là, c'est quand même assez binaire...
Ce n'est pas parce qu'une faille est découverte six mois après la sortie d'un logiciel, qu'elle n'était pas déjà présente au début.
"Ca ne sera pas moins sécurisé qu'aujourd'hui" dépend strictement de comment c'est aujourd'hui.
Yth.
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 0.
* Si tu as des gens pour faire des audits de sécurité, et coder des patchs pour tes applis, alors tu as des gens pour les migrer en PHP5 pour raisons de sécurité. Ce n'est qu'un patch de plus, pas forcément plus difficile à faire qu'un autre (ça reste globalement pareil PHP).
* Si tu ne développes pas l'appli toi-même, mais que tu te contentes de la maintenir à jour, pour raisons de sécurité, c'est elle qui passera à PHP5, pour raisons de sécurité.
Le seul argument qu'il te reste sont les patchs de sécurité PHP4.
Qui sont encore maintenus pour pas mal de temps, un an.
Ca laisse le temps de trouver une solution, si c'est vraiment critique, non ?
Et les problèmes de sécurité de PHP4 sont justement une des raisons de l'existence de PHP5. Donc, si c'est vraiment critique, alors, tu fais l'effort de migrer, non ? Et si ça ne l'est pas et que comme la plupart des gens tu as un PHP4 pas super à jour avec les tout derniers patchs, ça ne changera pas grand chose...
Yth.
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 3.
Le service LAMP avec PHP4 et tout un tas d'applis PHP4 dessus, il suffit de le laisser en place, et tout va continuer à fonctionner. Les sources sont (et seront) toujours disponibles. On pourra encore installer un PHP4 dans dix ans, même s'il faudra un Apache 2.2 maxi par exemple, il sera aussi disponible...
Les gens ne sont pas *obligés* de migrer !
surtout s'il s'agit d'un serveur entièrement géré par une entreprise et qu'elle n'a rien à demander à qui que ce soit.
L'idée là c'est plus que les services d'hébergements de pages web, sont incités à passer à PHP5. Dessus il y a majoritairement (j'insiste sur ce mot) des sites persos. Donc des forums, blogs, et cie, qui souvent vont très bien fonctionner en PHP5, pour peu éventuellement qu'une mise à jour soit faite.
En fait, je doute que cette annonce change vraiment grand chose pour les entreprises...
Je peux me tromper.
Yth.
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 3.
Je n'ai *aucune* idée de la réalité, et de l'importance, de cette incompatibilité entre PHP4 et PHP5. Globalement, ça marche pareil. Si on n'a pas de dev sous la main et que ça ne marche pas pareil, on peut bidouiller assez aisément avec apache pour avoir les deux.
Et je pense que dans la majeure partie des cas, il n'y a certes aucun besoin de passer de PHP4 à PHP5, mais aussi aucune difficulté, et que ça marche tout seul...
Alors je dis juste qu'il faut relativiser le problème, je ne crois pas qu'il y ait quoi que ce soit de dramatique...
D'un point de vue personnel, je n'aime pas le PHP, s'il est capable d'évoluer et de se débarrasser de ses défauts, je réviserait peut-être mon jugement, donc j'accueille la nouvelle plutôt bien !
Yth, qui retourne à son python, parce que le python, c'est bon !
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 4.
C'est même possible de faire cohabiter les deux dans un même apache. Là par contre tu auras peut-être intérêt à renommer tes fichiers .php qui doivent tourner en PHP4, en fichiers .php4 (et les liens internes aussi), mais c'est un assez moindre effort. Et pas besoin de regarder comment marche l'appli.
Ou alors de configurer apache pour lui dire que dans tel répertoire les fichiers .php sont à envoyer au module PHP4, et là, ya plus rien à changer à ton appli.
Bref, pour répondre au tout premier message, ça semble plus une bonne qu'une mauvaise idée. C'est aussi ça la force du libre : on n'est pas *obligé* de se traîner les boulets des erreurs de jeunesse des logiciels. On le voit bien avec le noyau Linux, il bouge énormément, cassant allègrement des vieilles compatibilités, au final on y gagne bien plus qu'on y perd.
Yth.
[^] # Re: [:aloy]
Posté par Yth (Mastodon) . En réponse au journal Hot line de matinée.... Évalué à 2.
;)
Yth...
[^] # Re: [:aloy]
Posté par Yth (Mastodon) . En réponse au journal Hot line de matinée.... Évalué à 4.
Ca défoule en fait ce message.
Faut que j'arrête de stresser moi dans la vie...
Ben bonne fin de journée les gens ^^
Yth.
[^] # Re: [:aloy]
Posté par Yth (Mastodon) . En réponse au journal Hot line de matinée.... Évalué à 10.
Le partage de connaissance, c'pas *que* pour résoudre les problèmes de conf de sendmail môssieur Ronchon !
Les critiques, c'est bien, ça fait progresser, si tout le monde te dit tout le temps que t'es génial quand tu fais des conneries, t'es pas prêt de t'améliorer.
Alors la prochaine fois t'écriras « c'est » et non « c », si tu as un minimum de respect pour les gros lourds, chiants, désagréables, et imbus d'eux-mêmes, comme moi, qui vont te lire. Parce que c'est juste du respect môssieur Ronchon. Parce qu'on peut ronchonner en étant respectueux des gens môssieur Ronchon !
Et surtout, sur ce site, il n'y a pas un « vous » qui regroupe les gens du site par opposition aux simples visiteurs. Les admins ils sont quatre pelés (bon, un peu plus), et c'pas forcément les plus bavards. Dans ce « vous êtes de plus en plus lourd », il y a toi, le gros lourd qui vient pour la énième milliardième fois encore inlassablement et tout aussi inutilement, te plaindre qu'il y a des gens qui sont lourds.
Putain, t'es vraiment lourd, mais quand est-ce qu'on pourra enfin, tranquillement, faire un petit message court, avec une note d'humour, informant juste des quelques fautes de français commises dans un journal ou une dépêche, sans qu'un gros lourd vienne avec ses gros sabots de gros lourd derrière dire « Aaaah, y'en a mare D gro lour ki fé D rmq sur le fôtes ! », fais chier !
Je revendique mon droit à corriger, aimablement, simplement, efficacement, et si possible humoristiquement, les erreurs de français commises par d'autres, sans avoir à me coltiner des gros lourds qui vont me répondre en langage SMS que je suis un gros lourd !
Je soutiens totalement Chrisix sur ce coup-là. En plus, c'était drôle.
Mais forcément un bon mot basé sur la subtilité d'écriture de deux mots qui se prononcent pareil mais ont des sens différents, ça ne peut se comprendre que si on fait des efforts pour bien écrire. Fais-les ces efforts, tu crèveras moins bête, en plus tu rigoleras à la lecture du message précédent, plutôt que de casser les couilles de tout le monde avec ton message aigri de gros lourd.
Yth, gros lourd, mais gros lourd qui t'emmerde.
[^] # Re: MAJ
Posté par Yth (Mastodon) . En réponse à la dépêche Par un beau jour d'été, Slackware 12.0 prend l'air.. Évalué à 2.
Quelle question...
Et oui, c'est possible de *ne pas* mettre à jour un paquet sous slack.
C'est même possible d'avoir en parallèle deux versions d'un même paquet ! Pour le cas où ça pourrait servir (ça m'est arrivé).
Ca t'en bouche un coin ?
Yth.
[^] # Re: MAJ
Posté par Yth (Mastodon) . En réponse à la dépêche Par un beau jour d'été, Slackware 12.0 prend l'air.. Évalué à 6.
T'adores faire de la provoc' hein ?
Il existe des outils permettant de savoir si le système est complet et s'ils ne manque pas de dépendances, et si oui, où elles manquent, et quelles elles sont.
Les choses se font différemment d'ailleurs, mais on peut faire les mêmes.
Et qu'est-ce que c'est que cette histoire de « les laisser penser qu'ils maîtrisent » ? Insultant maintenant en plus ? Les utilisateurs de la slack croient tout savoir mais sont des débiles ?
Ah ben charmant, vraiment, t'as le don pour te rendre sympathique toi...
Ben tu me rappelleras quand tu auras vraiment quelque chose à dire.
Cracher c'est fun, mais ça ne mène à rien tu sais.
Yth.
[^] # Re: MAJ
Posté par Yth (Mastodon) . En réponse à la dépêche Par un beau jour d'été, Slackware 12.0 prend l'air.. Évalué à 8.
Monsieur dit qu'il ne veut pas troller, et pourtant...
« si tu installe tous tes soft à la mains »
Et non !
C'est juste faux, la slack est très complète, et les logiciels que tu rajoutes sont purement et simplement des choix que tu fais différemment de ceux de Patrick, par exemple j'utilise windowmaker avec rox, et sylpheed, mais je pourrais utiliser xfce ou kde, avec thunderbird.
Dingue ça, trois paquets à ajouter, vraiment du délire...
Allez, j'ai aussi ajouté mplayer, graveman et psi.
Il y avait xine, xcdroast et pidgin.
Et je n'en ai compilé aucun, il y a des dépôts avec ce travail déjà effectué...
Pour tout le reste c'est là, tout les serveurs que tu veux, apache, php, python, ruby, perl, sendmail, proftpd, vsftpd, bind, dhcpcd, dnsmasq, que sais-je encore... des paquets, il y en a environ 900, et les logiciels ne sont pas découpés en truc-data, truc-devel, truc-lib, truc-main, donc ça correspond à beaucoup plus dans d'autres distribs.
« Dans toutes les distribs normales, tu es libre de pouvoir installer ce que tu veux comme tu veux, sans aucune contrainte (si si, même sous *untu ou m4ndr1v4 !), mais comme tu le souligne, tu romps avec ta distribution, ce qui n'est pas sans inconvénients. »
Et là, sous slack, tu ne romps *pas* avec ta distrib, faire un paquet est trivial, avec les pkgtool ou avec checkinstall, ton nouveau logiciel que tu as compilé toi-même s'intègre à ta distrib immédiatement, tu es libre de faire comme bon te semble et ceci en accord avec ta distrib.
Si ta liberté c'est celle de tout casser et de ne plus pouvoir profiter des outils de mise à jour et de la gestion des paquets, autant utiliser une LFS, je te retourne la question : quel intérêt alors d'utiliser une Debian, une Fedora, une Mandriva ?
Toi t'as juste envie de casser du bois sur le dos de la Slack, tu ne comprends pas son intérêt, ou qu'on puisse l'apprécier, laisse au moins ceux qui eux voient cet intérêt et apprécient cette distrib en paix, t'es pas prêt de me voir cracher sur Debian en disant qu'elle n'apporte rien. Mais moi, personnellement, je ne me sens pas à l'aise, même avec une Debian, elle m'étouffe.
Ma slack ne fait pas rien, je suis en slackware-current, mise à jour très régulièrement, toujours stable, toujours robuste, et ça n'entre pas en conflit avec ce que j'ajoute moi-même pour la personnaliser. Ma Slack c'est la mienne, unique, mais c'est aussi une Slackware 12.0 complète. Je n'ai pas fait de réinstallation complète, et mon vieux paquet dosemu-1.3.4 compilé à la mimine fonctionne toujours aussi bien, et je vais faire un beau paquet dosemu-1.4.0, qui est sorti il y a peu, et je dirais upgradepkg dosemu-1.4.0, il fera la mise à jour, et ça continuera à très bien marcher, et je continuerai d'avoir une Slackware 12.0, puis à nouveau une slackware-current, avec *mes* touches personnelles...
Pendant ce temps là, Xorg est mis à jour, KDE aussi, firefox, apache, python, et je ne fais rien à la main.
Alors dire que la Slackware est une distrib qui ne fait rien, c'est manquer singulièrement de flemme et de paresse, deux grande qualités de l'informaticien.
Yth, glandu, libre, et content.
[^] # Re: MAJ
Posté par Yth (Mastodon) . En réponse à la dépêche Par un beau jour d'été, Slackware 12.0 prend l'air.. Évalué à 9.
Un intérêt dépendant de comment tu veux, ou aime, faire les choses.
Ce n'est pas un intérêt pour une distrib avec l'objectif d'une mandriva ou d'une ubuntu, à volonté d'être très aisément utilisable par un néophyte (quel que puisse être leur degré de réussite dans ce domaine).
C'est un gros intérêt quand ce que tu recherches est un cadre solide, une base en acier, sur laquelle tu peux construire ce que tu veux, comme tu le veux, et sans aucune contrainte.
Parce que la slack ne t'impose rien, du tout, elle pose le nécessaire à faire fonctionner un système GNU/Linux complet, et à jour, simplement et efficacement. Après tu es libre, tu fais comme bon te semble et jamais ta slack ne se mettra sur ton chemin.
Ce qui est faux avec la très grande majorité des autres distribs, essentiellement celles qui ont des gestions de dépendances.
Tu essaieras avec une Debian de bricoler sur un paquet donné, et de casser tes dépendances, dpkg te dit que tel paquet pose problème, qu'il faut que tu le résolves. Et là tu te dis « ok, c'est complexe, pas le temps dans les cinq minutes, je verrai plus tard ». Ben tu peux pas, parce que la prochaine fois que tu voudras installer ou modifier un paquet quelconque, n'ayant *aucun* rapport avec ton paquet à problème, il te dira que ta Debian est cassée et qu'il *faut* que tu résolves ton problème avant. Et ça, c'est parfois extrêmement chiant, et quand tu es confronté à ce genre de situation ; parce que tu veux faire certaines choses comme tu veux les faire, et non comme ta distrib te dis qu'il faut les faire, et qu'elle t'en empêche.
D'où oui, c'est vraiment un intérêt. Pas pour tout le monde, par pour toutes les utilisations, mais un intérêt réel.
Et non, la slack n'est pas simplement un live-cd d'installation et un serveur ftp, c'est une distrib solide, stable, et fiable. Tu sais que si tu l'installes tu auras ta base, ton cadre connu et maîtrisé. C'est juste un gain de temps et d'efforts phénoménal, avec la liberté totale.
(Et je n'ai *jamais* dis que la Slack était un cas unique, et qu'aucune autre distrib pouvait rendre le même genre de service, merci de ne pas me faire dire ce que je n'ai pas dis, je prend les devants.)
Yth.
[^] # Re: Merci pour le ton
Posté par Yth (Mastodon) . En réponse à la dépêche Par un beau jour d'été, Slackware 12.0 prend l'air.. Évalué à 1.
Bon, tant pis, nul doute que ça s'arrangera rapidement.
Allez, slackpkg update, slackpkg install-new, slackpkg upgrade-all !
Yth.
[^] # Re: vendredi powered
Posté par Yth (Mastodon) . En réponse au journal à quand un code commenté ?. Évalué à 8.
Il répondra même aux questions. En soixante-sept langues, trente-quatre dialectes, quarante-sept idiomes, et deux-cent-trente-huit variantes locales ou argotiques.
Yth.
[^] # Re: u r not alone
Posté par Yth (Mastodon) . En réponse au journal à quand un code commenté ?. Évalué à 10.
J'ai même tendance à mieux commenter encore quand c'est pour moi, parce que j'ai le temps, pas de deadline pourrie et de trucs à rendre vite fait mal fait pour avant-hier.
Yth.
[^] # Re: Paradoxe ?
Posté par Yth (Mastodon) . En réponse au journal good bye my lover, good bye my friend.... Évalué à 1.
Ah ça, je ne prétendrai jamais le contraire. J'étais surtout assez surpris de l'unanimité qu'il semble faire contre lui !
Yth.
[^] # Re: Paradoxe ?
Posté par Yth (Mastodon) . En réponse au journal good bye my lover, good bye my friend.... Évalué à 5.
En tout cas, les commentaires sur le site de libération sont unanimement opposés à cet illustre inconnu parmi tant d'autres, qui n'a pas l'air particulièrement ouvert d'esprit sur autre chose que le profit rapide, au vu de l'article...
Yth.
[^] # Re: Apparemment ça ne passera pas
Posté par Yth (Mastodon) . En réponse au journal Une constitution votée sans le peuple. Évalué à 5.
Yth.
[^] # Re: DROD
Posté par Yth (Mastodon) . En réponse à la dépêche Des jeux Libres pour GNU/Linux. Évalué à 2.
Excellent jeu ce DROD.
Yth.
[^] # Re: Pour quoi slackware en 2007?
Posté par Yth (Mastodon) . En réponse au journal Slackware 12.0 RC1. Évalué à 2.
Yth.
[^] # Re: AMD ne doit pas se racheter...
Posté par Yth (Mastodon) . En réponse au journal Driver libre pour carte graphique AMD R500. Évalué à 4.
Mode de TCL : Utiliser le TCL matériel pour le premier niveau de pipeline.
A la place du défaut : Court-circuiter le pipeline TCL par une machine à états qui génère le code TCL à la volée.
J'ai aussi augmenté la « Size of command buffer (in kb) » de 8 à 32
Et j'ai aussi désactivé le « low-impact fallback ».
Je n'ai *aucune* idée de ce que tout ceci peut bien signifier ^^
En gros j'ai essayé de changer des trucs pour voir ce que ça donne, à première vue ça a des effets, en l'occurrence positifs.
Yth.
[^] # Re: Pour quoi slackware en 2007?
Posté par Yth (Mastodon) . En réponse au journal Slackware 12.0 RC1. Évalué à 5.
Alors oui, elle s'adresse plus à des gens qui veulent farfouiller dans la tripaille, et vraiment comprendre, et pas tellement à des gens qui ne veulent qu'être utilisateurs et avoir un système qui marche sans faire d'effort. Mais ces gens existent, la preuve ! (Non, non, je ne suis pas une émanation du réseau).
De plus, sachant que les logiciels sont les mêmes partout d'une distrib à l'autre, la Slackware, pourquoi pas ?
J'ai le même firefox, le même blender, le même sylpheed, le même psi, le même kde/windowmaker/xfce... (pas gnome :p), le même audacity, le même mplayer, et j'en passe, que sur n'importe quelle autre distribution.
Yth.