Excuse du peu, mais Lisaac se veut un langage pour faire un OS, et les exceptions existent aussi en C# (que certains utilisent pour faire un OS), en C++ (dont l'utilisation dans les OS n'est plus à démontrer).
Donc voilà, je me doute que c'est dans les priorité, mais j'aimerai savoir si vous avez avancé sur le sujet, parcque dans les derniers débats que j'avais eu, la notion de module avait l'air de foutre en l'air la notion d'optimisation global offerte par le compilo...
L'aspect OS était ces derniers temps en train de disparaître, même si il se met peu à peu à revivre ...
Pour les modules qui fouttent en l'air l'optimisation globale, c'est vrai. Mais il n'y a pas de solution miracle. Par contre, si l'application est bien développée, les interfaces entres modules seront réduites, ce qui permettra d'optimiser chaque module séparément comme avant, et de ne perdre que peu de performances à l'endroit des interfaces.
Vous semblez critiquez la notion d'exception, pourquoi pas, mais où sont les arguments/raisonnement ?
Perso, je n'ai rien contre, c'est plus Benoît, l'inventeur du langage qui ne les aime pas. Il me semble que le problème c'est que cela cause une rupture de flot (un peu comme les goto, les break, continue et return qui n'existent pas en Lisaac). Cette rupture de flot pose un problème il semblerait au niveau de la preuve des programmes par les contrats.
Mais je ne peux pas en dire plus, je n'en sais rien en fait.
Il me semble que wget conserve la date du document. J'ai pu m'en rendre compte car j'ai un dossier spécial ~/Inbox qui sert à recevoir tous les téléchargements que je fais. Et je le trie par date.
Les fichiers téléchargés par firefox viennent s'ajouter à la fin, mais avec wget, c'est au milieu.
On pourrait imaginer que l'application de mise à jour se personnalise avec le logo de la boîte et le nom de la boîte ... ça n'aurait pas du tout l'air de venir de Microsoft.
Par exemple, si ça s'appelle update.exe, lors de l'installation d'un programme, un raccourci vers update.exe est placé dans le menu démarrer avec en paramètres un fichier de configuration.
Et pour les problèmes de malware, ne suffirait-il pas d'exiger un serveur ayant un certificat de sécurité validé ?
En gros cela ressemblerait aux programmes de mise à jour que chaque boîte fait dans son coin, mais avec une base commune.
Je ne veux pas être désagréable mais bon ... Il y a un moment ou il faut arrêter de pleurer et agir.
C'est pas toujours facile d'agir, tu fais comment en pratique.
En parler ici est une forme d'action. Cela permet de partager ses idées, de montrer aux autres les problèmes, de chercher des solutions éventuellement. Pour ma part, je suis d'accord avec lui sur bien des points, mais il reste la question de comment contribuer ?
Le problème c'est qu'un individu dans son coin aura du mal à contribuer car il aura peu d'influence, les autres ne voyant pas le problème.
Je pense plutôt que si tu propose une interface standardisée, tu risque de te faire jeter avec pour prétexte “ça sert à rien ton truc”.
J'ai fait quelques essais (certes, pleins d'erreurs) sur la mailing list XDG (normalisation de freedesktop) -> aucune réponse. Sans doute personne ne percevait le besoin que j'avais. Il y avait peut être une personne qui m'a contactée pour me demander si j'avais réussi à aller quelque part, eh ben non.
Peut être devrais-je faire partie d'une équipe GNOME ou KDE, ça marcherait peut être mieux. Mais je ne peux pas m'y résoudre, trouvant des défaut dans chacun des deux environnements (et dans X11 plus globalement, le Grab du pointeur est souvent gênant, car empêche les autres applications d'avoir des informations importantes sur l'activité de l'utilisateur)
Cela dit aujourd'hui, les WM font des tas de trucs qu'ils ne devraient pas faire (gestion du réseau, accès aux FS, etc ...) et c'est vrai que ça devient n'importe quoi.
Je rêve d'un monde où les services session utilisateurs soient intégrés au maximum au système, pour pouvoir choisir son WM préféré qui n'a pas forcément tout développer, et continuer à pouvoir avoir une gestion de l'énergie.
Ou au moins, d'un monde où ces services de session ne soient pas liés à un WM.
Je trouve l'approche de NetworkManager mieux que celle prise pour la gestion de l'énergie. On a un daemon NetworkManager qui gère les connexions, sauf que le daemon qui gère la gestion de l'énergie doit être implémentée pour chaque WM.
Le mieux, ce serait une daemon se chargeant de la gestion de l'énergie, et une interface dBus pour le controller. Cela éviterait par la même occasion de devoir implémenter la gestion de l'énergie dans gdm.
Quand aux packages, j'ai peu d'espoir d'unification deb et rpm!
Pas besoin d'unifier deb et rpm. Ces packages là sont fait par les distributions. A mon avis ce qui est nécessaire c'est de distinguer dans les distributions les packages fournis par la distribution, et les packages d'une tierce partie. Ces derniers peuvent utiliser un autre format (mieux vaut un format complètement nouveau sinon il y aura toujours des déçus qui auraient préféré voir leur format adopté).
Pour ma part, je pense que commencer avec une solution minimale serait une bonne solution, quitte a l'améliorer par la suite. J'imagine déjà la possibilité avec PackageKit d'installer un paquet externe à la distribution. Le format serait un simple tar.gz contenant les binaires, sans rien d'autre. Sans méta-information.
C'est rudimentaire, mais ce serait déjà une avancée je pense. On pourrait sur son site web proposer le paquet, et il marcherait partout (même sur les distributions qui n'ont pas PackageKit, un simple tar xf suffirait). L'interêt de PackageKit serait que les fichiers seraient pris en compte par le système de paquets.
Ce n’est pas le développeur des applications qui proposent ce choix (lui il développe, son application c’est celle qui est dans le svn, il s’en tape des versions précédentes — en tant que dév.)
Dans certains cas, les dev. peuvent proposer ce choix. Tous ne sont pas uniquement dans leur svn (ou mercurial, c'est mieux) ... Par exemple des applications comme Firefox ou OpenOffice.org. Ces applications ont un suivi qualité, et si les dev. décident qu'une nouvelle version est stable, on peut leur faire confiance.
L'argumentaire classique revient à faire de l'utilisateur d'une distribution le “client” de cette dernière. Il utilise les applications de la distribution. Sauf que dans certains cas, l'utilisateur final n'a pas forcément ce désir ... et se sent d'avantage “client” du groupe de dev. qui font l'application (Firefox, OpenOffice.org, wine et j'en passe).
Dans ce dernier cas, il n'existe aucun outil pour faciliter le déploiment de telles applications, et on se retrouve très souvent à compiler à la main en outrepassant le système de paquets local (chose que je déteste, le système de paquet est utile dans le mesure où il recense tous les fichiers du système).
ah dans ce cas là je suivais de près les sortis noyaux en outre-passant ma distribution. Il n’y a pas 36 000 solutions si on veut la dernière version d’un logiciel X tout de suite
C'est cela que je regrette, le manque de solutions (techniquement faisable) face à un problème que pas mal de monde s'est posé où se posera au moins un jour dans sa vie de linuxien.
Sauf que pour le moment le public linuxien sait en majorité compiler les applications à la main. Mais il faut penser aux gens qui aiment linux sans forcément savoir compiler (et sans forcément pouvoir apprendre). J'en connais.
J'ai pourtant lu des réponses en ce sens. Les clients le payent pour ça, il peut bien faire le travail ... Et en tout cas, je n'ai pas encore eu l'occasion de lire une réponse proposant un outil adapté.
Ce qui serait bien c'est soit d'avoir un format de paquet commun et adapté à des applications tierces (faiblement intégrées à une distribution) qui soit adopté par chaque distribution. Mais à ma connaissance, ça n'existe pas.
un autre point est ton obsession de la part de marché. or "Linux" s'en fout, des parts de marché. ce ne sont pas elles qui fourniront les specifications des matériels pour pouvoir écrire des drivers : les fabricants se contenteront de fournir des drivers binaires, fermés, qui auront toutes les chances de mal marcher ou de ne plus marcher dès que le vent tournera. se transformer en un Windows ou un Mac n'intéresse pas les gens qui font "Linux".
Sauf que je ne pense pas que ce sera le cas. Les fabricants ont tout avantage que leur matériel fonctionne directement, sans avoir à installer un driver. Et c'est là que la politique de Linus qui ne veux pas standardiser les interfaces du noyau porte ses fruits.
Quant au problème de perception que tu évoques, “le problème est que tu crois que c'est un problème” ... laisse moi douter. Le système actuel à des défauts, ces défauts peuvent être réduits, cela nécessite une effort de prise en compte du problème et une effort de standardisation ... sauf que personne ne le fait.
J'ai bien des idées, mais dans mon coin, je me vois mal pondre un standard (qui manquera de légitimité sans aucun doute)
Si il n'y pas de paquets pour X c'est parce qu'il n'y a pas de paquet pour X et que personne ne l'a fait (pas intéressé)
Et pourquoi personne ne l'a fait ?
Probablement parce que le dev. (je suis de ceux là) à trouvé trop compliqué de faire un paquet, et donc a abandonné. Bien sûr il ne le criera pas partout, ça restera discret.
Pourquoi les dev. sous Windows (y compris les logiciels libres Windows) font des paquets pour Windows alors que les dev. Linux ne font pas des paquets pour Linux. A mon avis un grand nombre s'est posé la question, et devant la difficulté du problème ont abandonné.
Tu me répondras que Linux regroupe en fait une grande diversité de distributions. Mais, même dans leur diversité, beaucoup sont très similaires (avec notamment pas mal de choses normalisées par freedesktop.org, les bibliothèques systèmes sont les mêmes, souvent avec la même version ...). La complexité qu'un dev. à pour créer tout ses paquets est artificielle, il serait possible de faire des paquets qui marchent raisonnablement bien sur un nombre raisonnable de distributions sans trop se compliquer la vie je pense.
Bien sûr, il y aura toujours la distribution exotique, ou ancienne qui ne sera pas comme les autres, et ça ne marchera pas. Mais en attendant, beaucoup d'autres distributions pourront profiter du paquet standard. Et pour les autres, retour aux paquets spécifiques.
Pour réduire sa tolérance, je fais toujours un error_reporting(E_ALL) (par défaut c'est E_ALL~E_NOTICE), c'est à dire que tu n'a pas les avertissements.
Ce que je ne comprend pas, c'est qu'il n'y ait pas de fonction en php pour désactiver les magic quotes au runtime ... :/
Du coup, dans chacun de mes scripts (enfin, je ne fais plus beaucoup de php) je détecte la présente des magic quotes, et dans ce cas, j'enlève les quotes des variables $_GET $_POST et $_COOKIE récursivement. C'est chiant à faire.
Apprendre que ce sera supprimé pour PHP6, quel bonheur !
Surtout que je ne comprend pas à quoi ça sert niveau SQL, parce qu'en SQL, pour mettre une quote dans une chaîne, il suffit de faire 'l''église' (on double la quote), le \' n'est pas standard.
Enfin, le mieux, c'est d'utiliser les fonction d'encodage propre au SGBD, comme ça on est sûr.
Je trouve hg plus propre que git, c'est assez subjectif mais ...
Déjà, savoir que git est fait en partie de script bash me fait peur (comprendre, est-ce que ça va bien marcher avec des noms de fichiers compliqués, contenant des espaces et caractères unicode ?).
Ensuite, c'est d'avantage multiplateforme. Même si j'utilise exclusivement gnu/linux, je n'aime pas forcer le choix d'une plateforme (les OS libres peuvent aussi être autre chose qu'unix).
Et puis, j'ai fait l'efort de lire complètement le manuel mercurial (parce que je voulais l'utiliser) et je comprend bien comment ça fonctionne. Il me semble que sur certains points de détail, git est différent, et ça peut être perturbant.
Un repository git peut devenir très gros si on ne fait pas de git repack de temps en temps. Cela oblige à faire des opérations de maintenance régulièrement (et le repack peut prendre du temps). Par contre, un repository git repaqueté sera plus léger qu'un repository mercurial (l'avantage de l'inconvénient).
Dans le temps j'avais regardé ... et c'était encore très expérimental, mais c'est un bon langage je pense.
Pourquoi pas ?
Mais, si j'avais choisi C# c'était aussi en partie pour avoir un environnement de développement qui me facilite la vie. Mais c'est vrai que c'est à double tranchant, dans un certain sens, ça limite aussi.
Je crois qu'avec ArchLinux, on dispose d'un gestionnaire de paquets exceptionnels. J'ai regardé un peu à droite et à gauche, mais je n'ai encore trouvé aucun gertionnaire de paquets où il soit plus facile de créer des paquets.
Donc, si le gestionnaire de paquets d'OpenSolaris est au niveau de rpm ou deb, c'est normal que ce ne soit pas facile.
Maintenant, j'espère que cela deviendra de plus en plus facile de créer des paquets perso avec les autres systèmes de paquets, mais je n'ai pas l'impression que ça intéresse beaucoup de monde.
Rappel: créer un paquet avec ArchLinux (pacman) nécessite une connaissance des script shell, et une page de lecture pour les quelques spécificités. À comparer aux 50 pages du guide du mainteneur debian ... et au nombre d'outils qu'il doit maîtriser pour créer et mettre à jour ses paquets.
Je profite de cette dépêche pour demander aux spécialistes si mercurial intègre maintenant (je crois que c'était vaguement en projet) la possibilité d'exporter vers un dépôt git facilement.
L'histoire c'est que j'aimerais bien pouvoir utiliser mercurial (que j'adore) à la place de git pour les projets utilisant git. Je sais que l'utilisation est très similaire, mais il y a quand même des différences ...
J'ai lu le texte, il m'a l'air bien rigolo. Je m'attendais à une critique un peu constructive du logiciel libre (par exemple : pourquoi des critères si restrictifs pour les licences libres ?). Mais non.
Une description humoristique, à donner aux païens adorant les logiciels privateurs :)
En fait c'est une histoire de crédit. Il semble que les 3 suisses proposent de payer en plusieurs fois ... Mais c'est vrai que ça doit pouvoir se trouver ailleurs aussi.
De toute façon, c'est assez urgent (je donne mon avis ce soir ou demain), donc je ne vais peut être pas pouvoir chercher de partout (surtout que j'ai aussi plein d'autres choses à faire)
C'est pourquoi le rapprochement que tu as fait est abusif de mon point de vue.
En quoi le problème que ce soit héréditaire dans ce cas change la problématique ? Le problème c'est la non acceptation de la société, et je ne vois pas le rapport avec l'hérédité. Pourquoi définir une frontière entre d'une part les minorités culturelles ou héréditaires et d'autre part les autres minorités ? Certaines serait-elles plus dignes d'être protégées que d'autres ?
Si les minorités culturelles peuvent être discriminées, c'est parce qu'elles ont une comportement différent des autres personnes. Et cela peut créer un malaise qui peut mener à une discrimination volante. Mais la minorité n'a pas besoin d'être culturellement différente pour avoir des comportements différents qui peuvent choquer et entrainner une discrimination.
J'ai l'impression que la disparition de la seconde page à entrainé une disparition de pas mal de journaux. De plus le système de notation est peut être néfaste à ce genre de journaux.
Ce serait bien si on pouvait la remettre. Une seconde page qui contiendrait que des journaux hors sujet ... Comme c'est en seconde page, il n'y aurait pas de notes trop négative sous prétexte que c'est hors sujet.
[^] # Re: beaucoup de blabla, peu d'info
Posté par Mildred (site web personnel) . En réponse au journal Retour sur le Isaac Meeting 2008. Évalué à 2.
Donc voilà, je me doute que c'est dans les priorité, mais j'aimerai savoir si vous avez avancé sur le sujet, parcque dans les derniers débats que j'avais eu, la notion de module avait l'air de foutre en l'air la notion d'optimisation global offerte par le compilo...
L'aspect OS était ces derniers temps en train de disparaître, même si il se met peu à peu à revivre ...
Pour les modules qui fouttent en l'air l'optimisation globale, c'est vrai. Mais il n'y a pas de solution miracle. Par contre, si l'application est bien développée, les interfaces entres modules seront réduites, ce qui permettra d'optimiser chaque module séparément comme avant, et de ne perdre que peu de performances à l'endroit des interfaces.
C'est mon idée en tout cas. Mais pour le moment il n'y a aucun code de ce coté. Mais c'est prévu: http://mildred817.online.fr/Misc/Computer/Lisaac/Specs/Futur(...)
(note, ce sont mes idées, cela ne sera probablement pas intégré dans Lisaac tel quel)
[^] # Re: beaucoup de blabla, peu d'info
Posté par Mildred (site web personnel) . En réponse au journal Retour sur le Isaac Meeting 2008. Évalué à 2.
Perso, je n'ai rien contre, c'est plus Benoît, l'inventeur du langage qui ne les aime pas. Il me semble que le problème c'est que cela cause une rupture de flot (un peu comme les goto, les break, continue et return qui n'existent pas en Lisaac). Cette rupture de flot pose un problème il semblerait au niveau de la preuve des programmes par les contrats.
Mais je ne peux pas en dire plus, je n'en sais rien en fait.
# wget
Posté par Mildred (site web personnel) . En réponse au journal Date de fichier. Évalué à 2.
Les fichiers téléchargés par firefox viennent s'ajouter à la fin, mais avec wget, c'est au milieu.
[^] # Re: wpm
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 2.
Par exemple, si ça s'appelle update.exe, lors de l'installation d'un programme, un raccourci vers update.exe est placé dans le menu démarrer avec en paramètres un fichier de configuration.
Et pour les problèmes de malware, ne suffirait-il pas d'exiger un serveur ayant un certificat de sécurité validé ?
En gros cela ressemblerait aux programmes de mise à jour que chaque boîte fait dans son coin, mais avec une base commune.
[^] # Re: Problème sous linux aussi
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 3.
C'est pas toujours facile d'agir, tu fais comment en pratique.
En parler ici est une forme d'action. Cela permet de partager ses idées, de montrer aux autres les problèmes, de chercher des solutions éventuellement. Pour ma part, je suis d'accord avec lui sur bien des points, mais il reste la question de comment contribuer ?
Le problème c'est qu'un individu dans son coin aura du mal à contribuer car il aura peu d'influence, les autres ne voyant pas le problème.
[^] # Re: Problème sous linux aussi
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 2.
J'ai fait quelques essais (certes, pleins d'erreurs) sur la mailing list XDG (normalisation de freedesktop) -> aucune réponse. Sans doute personne ne percevait le besoin que j'avais. Il y avait peut être une personne qui m'a contactée pour me demander si j'avais réussi à aller quelque part, eh ben non.
Peut être devrais-je faire partie d'une équipe GNOME ou KDE, ça marcherait peut être mieux. Mais je ne peux pas m'y résoudre, trouvant des défaut dans chacun des deux environnements (et dans X11 plus globalement, le Grab du pointeur est souvent gênant, car empêche les autres applications d'avoir des informations importantes sur l'activité de l'utilisateur)
[^] # Re: De l'utilité...
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 2.
Je rêve d'un monde où les services session utilisateurs soient intégrés au maximum au système, pour pouvoir choisir son WM préféré qui n'a pas forcément tout développer, et continuer à pouvoir avoir une gestion de l'énergie.
Ou au moins, d'un monde où ces services de session ne soient pas liés à un WM.
Je trouve l'approche de NetworkManager mieux que celle prise pour la gestion de l'énergie. On a un daemon NetworkManager qui gère les connexions, sauf que le daemon qui gère la gestion de l'énergie doit être implémentée pour chaque WM.
Le mieux, ce serait une daemon se chargeant de la gestion de l'énergie, et une interface dBus pour le controller. Cela éviterait par la même occasion de devoir implémenter la gestion de l'énergie dans gdm.
[^] # Re: De l'utilité...
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 2.
Pas besoin d'unifier deb et rpm. Ces packages là sont fait par les distributions. A mon avis ce qui est nécessaire c'est de distinguer dans les distributions les packages fournis par la distribution, et les packages d'une tierce partie. Ces derniers peuvent utiliser un autre format (mieux vaut un format complètement nouveau sinon il y aura toujours des déçus qui auraient préféré voir leur format adopté).
Pour ma part, je pense que commencer avec une solution minimale serait une bonne solution, quitte a l'améliorer par la suite. J'imagine déjà la possibilité avec PackageKit d'installer un paquet externe à la distribution. Le format serait un simple tar.gz contenant les binaires, sans rien d'autre. Sans méta-information.
C'est rudimentaire, mais ce serait déjà une avancée je pense. On pourrait sur son site web proposer le paquet, et il marcherait partout (même sur les distributions qui n'ont pas PackageKit, un simple tar xf suffirait). L'interêt de PackageKit serait que les fichiers seraient pris en compte par le système de paquets.
[^] # Re: De l'utilité...
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 2.
[^] # Re: Problème sous linux aussi
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 2.
Dans certains cas, les dev. peuvent proposer ce choix. Tous ne sont pas uniquement dans leur svn (ou mercurial, c'est mieux) ... Par exemple des applications comme Firefox ou OpenOffice.org. Ces applications ont un suivi qualité, et si les dev. décident qu'une nouvelle version est stable, on peut leur faire confiance.
L'argumentaire classique revient à faire de l'utilisateur d'une distribution le “client” de cette dernière. Il utilise les applications de la distribution. Sauf que dans certains cas, l'utilisateur final n'a pas forcément ce désir ... et se sent d'avantage “client” du groupe de dev. qui font l'application (Firefox, OpenOffice.org, wine et j'en passe).
Dans ce dernier cas, il n'existe aucun outil pour faciliter le déploiment de telles applications, et on se retrouve très souvent à compiler à la main en outrepassant le système de paquets local (chose que je déteste, le système de paquet est utile dans le mesure où il recense tous les fichiers du système).
ah dans ce cas là je suivais de près les sortis noyaux en outre-passant ma distribution. Il n’y a pas 36 000 solutions si on veut la dernière version d’un logiciel X tout de suite
C'est cela que je regrette, le manque de solutions (techniquement faisable) face à un problème que pas mal de monde s'est posé où se posera au moins un jour dans sa vie de linuxien.
Sauf que pour le moment le public linuxien sait en majorité compiler les applications à la main. Mais il faut penser aux gens qui aiment linux sans forcément savoir compiler (et sans forcément pouvoir apprendre). J'en connais.
[^] # Re: Problème sous linux aussi
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 2.
J'ai pourtant lu des réponses en ce sens. Les clients le payent pour ça, il peut bien faire le travail ... Et en tout cas, je n'ai pas encore eu l'occasion de lire une réponse proposant un outil adapté.
Ce qui serait bien c'est soit d'avoir un format de paquet commun et adapté à des applications tierces (faiblement intégrées à une distribution) qui soit adopté par chaque distribution. Mais à ma connaissance, ça n'existe pas.
[^] # Re: Problème sous linux aussi
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 3.
Sauf que je ne pense pas que ce sera le cas. Les fabricants ont tout avantage que leur matériel fonctionne directement, sans avoir à installer un driver. Et c'est là que la politique de Linus qui ne veux pas standardiser les interfaces du noyau porte ses fruits.
Quant au problème de perception que tu évoques, “le problème est que tu crois que c'est un problème” ... laisse moi douter. Le système actuel à des défauts, ces défauts peuvent être réduits, cela nécessite une effort de prise en compte du problème et une effort de standardisation ... sauf que personne ne le fait.
J'ai bien des idées, mais dans mon coin, je me vois mal pondre un standard (qui manquera de légitimité sans aucun doute)
[^] # Re: Problème sous linux aussi
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 3.
Et pourquoi personne ne l'a fait ?
Probablement parce que le dev. (je suis de ceux là) à trouvé trop compliqué de faire un paquet, et donc a abandonné. Bien sûr il ne le criera pas partout, ça restera discret.
Pourquoi les dev. sous Windows (y compris les logiciels libres Windows) font des paquets pour Windows alors que les dev. Linux ne font pas des paquets pour Linux. A mon avis un grand nombre s'est posé la question, et devant la difficulté du problème ont abandonné.
Tu me répondras que Linux regroupe en fait une grande diversité de distributions. Mais, même dans leur diversité, beaucoup sont très similaires (avec notamment pas mal de choses normalisées par freedesktop.org, les bibliothèques systèmes sont les mêmes, souvent avec la même version ...). La complexité qu'un dev. à pour créer tout ses paquets est artificielle, il serait possible de faire des paquets qui marchent raisonnablement bien sur un nombre raisonnable de distributions sans trop se compliquer la vie je pense.
Bien sûr, il y aura toujours la distribution exotique, ou ancienne qui ne sera pas comme les autres, et ça ne marchera pas. Mais en attendant, beaucoup d'autres distributions pourront profiter du paquet standard. Et pour les autres, retour aux paquets spécifiques.
[^] # Re: Correction
Posté par Mildred (site web personnel) . En réponse au journal Se faire rembourser Windows devient financièrement intéressant. Évalué à 3.
[^] # Re: Gasp ...
Posté par Mildred (site web personnel) . En réponse au journal N'installez pas PHP 5.2.7 !. Évalué à 2.
[^] # Re: D'aiSécurité des magic quotes ?
Posté par Mildred (site web personnel) . En réponse au journal N'installez pas PHP 5.2.7 !. Évalué à 1.
Du coup, dans chacun de mes scripts (enfin, je ne fais plus beaucoup de php) je détecte la présente des magic quotes, et dans ce cas, j'enlève les quotes des variables $_GET $_POST et $_COOKIE récursivement. C'est chiant à faire.
Apprendre que ce sera supprimé pour PHP6, quel bonheur !
Surtout que je ne comprend pas à quoi ça sert niveau SQL, parce qu'en SQL, pour mettre une quote dans une chaîne, il suffit de faire 'l''église' (on double la quote), le \' n'est pas standard.
Enfin, le mieux, c'est d'utiliser les fonction d'encodage propre au SGBD, comme ça on est sûr.
[^] # Re: Conversion transparente depuis et vers git ?
Posté par Mildred (site web personnel) . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 1.
Déjà, savoir que git est fait en partie de script bash me fait peur (comprendre, est-ce que ça va bien marcher avec des noms de fichiers compliqués, contenant des espaces et caractères unicode ?).
Ensuite, c'est d'avantage multiplateforme. Même si j'utilise exclusivement gnu/linux, je n'aime pas forcer le choix d'une plateforme (les OS libres peuvent aussi être autre chose qu'unix).
Et puis, j'ai fait l'efort de lire complètement le manuel mercurial (parce que je voulais l'utiliser) et je comprend bien comment ça fonctionne. Il me semble que sur certains points de détail, git est différent, et ça peut être perturbant.
Un repository git peut devenir très gros si on ne fait pas de git repack de temps en temps. Cela oblige à faire des opérations de maintenance régulièrement (et le repack peut prendre du temps). Par contre, un repository git repaqueté sera plus léger qu'un repository mercurial (l'avantage de l'inconvénient).
[^] # Re: [HS] le langage D ?
Posté par Mildred (site web personnel) . En réponse au message Où trouver la documentation de dbus-sharp ?. Évalué à 2.
Pourquoi pas ?
Mais, si j'avais choisi C# c'était aussi en partie pour avoir un environnement de développement qui me facilite la vie. Mais c'est vrai que c'est à double tranchant, dans un certain sens, ça limite aussi.
[^] # Re: Compatibilité limite avec KVM
Posté par Mildred (site web personnel) . En réponse à la dépêche Sortie d'Opensolaris 2008.11. Évalué à 4.
Donc, si le gestionnaire de paquets d'OpenSolaris est au niveau de rpm ou deb, c'est normal que ce ne soit pas facile.
Maintenant, j'espère que cela deviendra de plus en plus facile de créer des paquets perso avec les autres systèmes de paquets, mais je n'ai pas l'impression que ça intéresse beaucoup de monde.
Rappel: créer un paquet avec ArchLinux (pacman) nécessite une connaissance des script shell, et une page de lecture pour les quelques spécificités. À comparer aux 50 pages du guide du mainteneur debian ... et au nombre d'outils qu'il doit maîtriser pour créer et mettre à jour ses paquets.
# Conversion transparente depuis et vers git ?
Posté par Mildred (site web personnel) . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 2.
L'histoire c'est que j'aimerais bien pouvoir utiliser mercurial (que j'adore) à la place de git pour les projets utilisant git. Je sais que l'utilisation est très similaire, mais il y a quand même des différences ...
# Rigolo
Posté par Mildred (site web personnel) . En réponse au journal Un candidat au troll du vendredi. Évalué à 3.
Une description humoristique, à donner aux païens adorant les logiciels privateurs :)
[^] # Re: aux 3 suisses ?
Posté par Mildred (site web personnel) . En réponse au message Qu'est ce qui peux ne pas marcher sur un portable ?. Évalué à 2.
De toute façon, c'est assez urgent (je donne mon avis ce soir ou demain), donc je ne vais peut être pas pouvoir chercher de partout (surtout que j'ai aussi plein d'autres choses à faire)
[^] # Re: L'émission
Posté par Mildred (site web personnel) . En réponse au journal Defier la loi du genre. Évalué à 2.
http://dl.free.fr/oIp6jWql3
http://dl.free.fr/llegIUQOO
[^] # Re: traduction littérale ?
Posté par Mildred (site web personnel) . En réponse au journal Defier la loi du genre. Évalué à 2.
En quoi le problème que ce soit héréditaire dans ce cas change la problématique ? Le problème c'est la non acceptation de la société, et je ne vois pas le rapport avec l'hérédité. Pourquoi définir une frontière entre d'une part les minorités culturelles ou héréditaires et d'autre part les autres minorités ? Certaines serait-elles plus dignes d'être protégées que d'autres ?
Si les minorités culturelles peuvent être discriminées, c'est parce qu'elles ont une comportement différent des autres personnes. Et cela peut créer un malaise qui peut mener à une discrimination volante. Mais la minorité n'a pas besoin d'être culturellement différente pour avoir des comportements différents qui peuvent choquer et entrainner une discrimination.
# Disparus avec la seconde page
Posté par Mildred (site web personnel) . En réponse au journal Fréquence journaux, fréquence dépêches. Évalué à 3.
Ce serait bien si on pouvait la remettre. Une seconde page qui contiendrait que des journaux hors sujet ... Comme c'est en seconde page, il n'y aurait pas de notes trop négative sous prétexte que c'est hors sujet.