> Si tu veux du moins restrictif, prend une licence BSD. L'histoire a montré que tous les bons produits sous Licence BSD finisse par être proprio et sans le moindre retour à la communauté.
J'oubliais que NetBSD, FreeBSD, OpenBSD, XFree, Zsh, oggenc, PMK, Apache, Webmin, PostgreeSQL, LFS, tcpdump, E, hdparm, les *box, X et bon je vais pas faire tout la liste non plus sont tous devenus proprio et ce sans le moindre retour a la communauté.
> Ensuite avec pwcx, tu devrais pouvoir l'utiliser sans probleme, sans pour autant patcher ton noyau (le module inclus dans le noyau pour pwc (qui est DIFFERENT de pwcx) marche tres bien, quand il est couplé a pwcx).
Non pwcx est packagé comme de la merde en boite jusqu'a la version 8. Tu es obligé de forcer l'insertion. Et en 2.6 j'en parle même pas. D'autant plus qu'il y a un bug dans pwc (ou gm) qui force a utiliser pwcx dans les gm pre-1.0.
La bonne nouvelle c'est que pwcx 9 arrange tout ces problemes. La mauvaise nouvelle c'est que c'est en BETA1 (mais aucun problemes) depuis plus de deux mois.
Et gnomemeeting n'est pas simple a utiliser, nombreux reglages et souvent des problemes.
J'arrive pas a voir en quoi elle pourrait faire moins peur en XML franchement. C'est juste une syntaxe différente. Tu aurais eu aussi peur en XML et en plus lire une DTD c'est chiant donc tu aurais lu la doc, donc ca revient au même pour l'humain.
Un exemple flagrant est l' ebuild contre spell (gentoo / sourcemage). On peut faire a peu pres la meme chose mais l'expressivité n'est pas vraiment la même...
Une solution serait que le module de configuration ait une representation interne en XML mais qu'il ecrive dans le fichier dans le format initial. Sous forme de plugin pour chaque application.
> Bah c'est quand meme plus lisible qu'une suite de baragouinement avec des 0 0 sync,rw et consorts
Non la syntaxe d'fstab te donne tout de suite ce que tu cherches. La ligne est simple clair conscise. Ton charabiat d'XML il faut chercher les infos avec les yeux. Un fstab comme le tien avec 25 partitions de montées serait d'une lisibilité folle.
> Ca ne t'apprend pas a te servir du truc, mais tu sais de quoi ca parle au moins, et si il manque une virgule ou autre chose, tu a la dtd
lire une DTD est follement plus amusant que de faire less fstab
vi spécial comme ceux utilisé pour l'édition de la crontab et de sudo
rien ne t'oblige d'utiliser un vi special. C'est juste pour t'eviter de casser ton systeme. Le XML ne t'empechera pas de faire ca.
> En plus, la coloration est directement faite
Heu moi vim me dit quand j'ai tappé
proc /proc proc defaulst (le defaulst est pas en jaune)
Alors que des editeurs de textes qui serait capable de detecter qu'un
<option> defaulst<> c'est plus rare.
> Et enfin, ca faciliterait et éviterait l'éparpillement des outils spécifiques au distrib, en fournissant par exemple un noyau a ceux-ci, qu'il implémenterait en ajoutant leur interface dessus.
Ca c'est un vrai problème pour faire une interface unifiée pour la config.
> Et sinon, a propos de pmk, ya beaucoup de projet qui l'utilise?
Pas enormement c'est jeune et comme tout projet jeune dans ces domaines avoir une dependence contre PMK est pénalisante. CONS et SCONS ont le même problème il me semble.
> je me suis rendu compte qu'a chaque fois que j'apprenais a me servir d'un truc, il fallait quasiment repartir a zéro.
Tu apprends l'outil de zero c'est normal. En quoi apache t'as appris quelque chose sur postfix ?
> Un exemple simple serait les fichiers de configurations, qui n'ont absolument pas, et jamais la même syntaxe. Alors oui, c'est normal que shorewall et apache n'est pas les mêmes fichiers de conf, mais quand même, n'y aurait il pas moyen d'unifier cela un peu plus?
L'unification de quoi ?
XML est juste un langage de balisage. Si out les projets utilisaient XML et leur propre DTD tu serais pas tellement plus avancé hormis d'avoir un fichier illisible rempli de < > </ >.
Autrement ce que tu cherches se nomme une base de registre.... :-)
> qui utilise des *.po, des *.mo et des *.gmo, encore une fois dans une logique des plus étranges
Bin c'est pas les GNUs qui ont inventés ca ? :-)
> Un dernier exemple qui me sidère sont les logiciels d'autoconf, qui se révèlent être un beau boxon si on veut initier un projet dessus.
Posté par ckyl .
En réponse au journal Idée du jour.
Évalué à 1.
> Pourtant, les libs utilisées dans un source, elles sont forcément spécifiées quelque part en clair non ? En c, par exemple, je colle des -lmachin au gcc. Un programme peut déjà analyser ça.
A ouai mais non :-)
Le problème est que tu ne sais pas sous quelle forme se présente l'information. Faudrait avoir une analyse semantique tres (trop) poussée.
En fait que tu veux faire ressemble un peu a faire ce que faire un packageur a priori alors qu'un packageur le fait a priori et a posteriori.
Pour ma part, generalement je connais assez bien les dependences basiques des softs donc on commence par faire une première version. Une fois que le truc marche il y a un script shell qui essait de regarder si par hasard j'aurais pas oublié une dep, par exemple parsage de ldd pour un libxml ratée....
Tu peux aussi imaginer un logiciel en c qui fasse un system("perl xxxxx"). Ton programme pour fonctionner a besoin de Perl, mais cette info n'est dispo que dans le INSTALL ou dans le code.
> - Parfois, les fichiers packagés, s'ils existent, sont trop anciens (il y a toujours un décalage entre la sortie de la dernière version stable et celle du package).
C'est le problème d'une distrib binaire, commencer a tout recompiler n'est pas une solution.
> - Souvent, toutes les distribs sont loin d'être réprésentées
> - Si un logiciel est trop "petit", personne ne va s'embêter à faire des packages.
Faux si le logiciel est inutile personne ne va s'embetter. Generalement les packageurs sont curieux, et les applis sympas ne mettent pas longtemps a avoir un package utilisable (je ne dis pas forcement package officiel). Surtout s'il s'agit de quelque de pas enorme, pour sourcemage ou les spells sont tres facile a faire, en 4 minutes je peux te faire un spell installable (je ne parle pas de qualité la :-).
> Quand à lire un fichier INSTALL, je le fais à chaque fois, et je trouve (sincèrement) que 80% d'entre eux sont incomplets ou faux (libs nécessaires erronées ou non listées, etc.)
Dans ce cas basiquement du fait ./configure il t'insulte il te dit qu'il ne peut pas trouver libmachinechose et tu as juste a faire (apt-get install|urpmi|cequetuveux) libmachinchose(-dev ?). C'est le cas simple que ton prog a effectivement une chance de gerer. Mais un utilisateur un tout petit petit peu degourdi ne ferait-il pas exactement le meme chose ? Autrement encore une fois tout ce qu'il va faire c'est foutre le bordel sur sa machine.
> [ mastermind ]
Ton logiciel ne pourra rien contre les logiciels mal packagés. Par exemple on ne peut pas avoir Gnomemeeting 1.0 sur sourcemage pour le moment par ce qu'on est au moins 4 a s'etre peté les dents dessus... Alors qu'en le compilant a la main il n'y a pas de problèmes.
Un truc qui me semble plus interessant que ce que tu comptes faire serait d'adapter portage/sorcery/autre pour qu'il sachent gerer les dependences rpm/deb. C'est a dire de modifier la libdepends par exemple pour qu'il essait d'abord les methodes officielles de la distribution et d'utiliser tout le reste. Et la dessus tu peux facilement faire une interface graphique. Mais ce n'est plus ton logiciel qui fait le boulot des packageurs.
Gcc a été appelé a 03:09:34, l'ancienne glibc a été finie de compiler a 23:0340 (dispel = suppression de l'ancienne glibc) et l'installation s'est terminée à 23:0347 le temps d'installer tout les fichiers.
Donc sur un pauvre Athlon 1.2Ghz 40 minutes a tout casser.
Posté par ckyl .
En réponse au journal Idée du jour.
Évalué à 1.
1/ Projet irrealisable par un logiciel
Pour avoir packagé un nombre non negligeable d'applications dans des distros sources je peux te dire qu'il est inconcevable de faire un logiciel qui sache automatiquement tout compiler et gerer les dépendences. Déjà avec les les usines a gazes^W^W^Woutils GNU c'est bien le bordel (regarde des packages comme insight) mais je tu ajoutes a ca tout les softs qui n'utilisent pas les outils GNU et c'est pas réalisable comme projet ( a moins de monter une usines a gaze ^100).
Genre tu as la petite applis du style gtk2-ssh-askpass le spell sourcemage resultant est pour la compilation / installation :
(
sedit "s/gcc/gcc $CFLAGS/" Makefile &&
make &&
prepare_install &&
cp gtk2-ssh-askpass /usr/bin/ &&
if [ ! -e /usr/libexec/ssh-askpass ] ; then
ln -s /usr/bin/gtk2-ssh-askpass /usr/libexec/ssh-askpass
fi
) > $C_FIFO 2>&1
Je te met au défi de retrouver les libs qu'il utilise, et comment construire (le gars devait pas savoir faire de Makefile :-)
De plus comment tu gères les dependences de facon generique ?
Bref ce n'est absolument pas rationel étant donnée que le nombre de types de fichier en entrée est "infini" de même que les formats de sortie.
2/ C'est inutile
Celui qui compile son application doit savoir ce qu'il fait. Autrement qu'il utilise les packages de sa distribution. Je ne vois aucun interet a ce genre de chose. Si le gus est incapble de faire un less INSTALL && faire ce qu'il y a dit dedans je ne vois pas l'interet qu'il pourrait tirer de sa compilation. Hormis tout casser.
Si l'application n'est pas packagée le plus simple est d'envoyer un mail gentil sur la ml de dev de la distribution que tu utilises. Si l'outil interesse quelqu'un tu as de grandes chances d'avoir ton package dans la semaine.
3/ C'est deja fait
Ca s'appelle une distribution source. Et si pour le moment les packageurs n'ont pas été remplacer par des algorithmes il y a peut etre une raison...
Tu reinventes la roue en bordelique et pas très rationel quoi
Et la réalité est bien triste pour Debian. Si sortir une version quand elle est prête est louable, ne jamais sortir de version est autre chose. J'ai pas trop suivit l'histoire mais si la modification du contrat social affecte la sortie de la sarge c'est completement con. Le travail a l'air d'etre, presque, achevé. Repousser un truc qui pourrait etre fait pour ce genre de motif est assez risible; qu'est ce qui l'est empêche de sortir une version stable maintenant et une version stable et triée dans 1 ans ? Ce ne me semble par être le genre d'impératif qui justifie de repousser une version majeure d'un produit.
S'amusez a ce genre de chose c'est soit n'en avoir vraiment rien a foutre de ses utilisateurs soit du masochisme.
Donc pour toi une version stable c'est un truc hors d'age sur lequel on met tout le code recent en backport ? C'est vrai que le concept est pas mal....
En même temps si tu peux encore modifier les sysctl/proc alors que le système fonctionne tu ferais mieux de retirer totalement ton grsec. Ca evitera de te bouffer 12 cycles CPUs pour rien.
Il faut bien entendu faire un lock au boot et empecher chargement de module/access aux disques/mem
que tout systeme a des erratas et des binaires pour patcher les merdes et les trous de sécu de la release.
> C'est quoi tes lignes absconses à propos de python ?
Un joli exemple d'appli qui leak dans les 1.5 Mo de RAM a l'heure. Et qui donc necessiterait une mise a jour qui demanderait un peu de bande passante pour mettre a jour.
Il me semble que si tu ne veux patcher que ce qui fait "que ton OS se planterait au bout d'une semaine" tu n'as pas 1 Go de download par mois non plus...
Les windows update ont exactement leur equivalent sous linux entre les mises a jour de packages foireux et les trous de sécu. C'est vrai que trois failles dans le noyau ca ne fait que 3 x 25 Mo a downloader...
Et des fois on aimerai meme un peu plus de mise a jour des packages foireux :
[^] # Re: Modules non GPL et tours de passe-passe
Posté par ckyl . En réponse à la dépêche Modules non GPL et tours de passe-passe. Évalué à 1.
J'oubliais que NetBSD, FreeBSD, OpenBSD, XFree, Zsh, oggenc, PMK, Apache, Webmin, PostgreeSQL, LFS, tcpdump, E, hdparm, les *box, X et bon je vais pas faire tout la liste non plus sont tous devenus proprio et ce sans le moindre retour a la communauté.
T'as pas honte de dire des conneries comme ca ?
> PS : MS adore la BSD et déteste la GPL.
Donc tu fais tes choix pour emmerder MS ?
En plus maintenant MS joue le jeux en mettant la license clairement http://www.microsoft.com/resources/documentation/WindowsServ/2003/e(...)
Regarde bien tu devrais voir luigi rizzo.
[^] # Re: Linux, webcam, messenger et débutant, c'est pas encore ca
Posté par ckyl . En réponse au journal Linux, webcam, messenger et débutant, c'est pas encore ca. Évalué à 1.
Non pwcx est packagé comme de la merde en boite jusqu'a la version 8. Tu es obligé de forcer l'insertion. Et en 2.6 j'en parle même pas. D'autant plus qu'il y a un bug dans pwc (ou gm) qui force a utiliser pwcx dans les gm pre-1.0.
La bonne nouvelle c'est que pwcx 9 arrange tout ces problemes. La mauvaise nouvelle c'est que c'est en BETA1 (mais aucun problemes) depuis plus de deux mois.
Et gnomemeeting n'est pas simple a utiliser, nombreux reglages et souvent des problemes.
[^] # Re: Remplacer les outils de base de Linux
Posté par ckyl . En réponse au journal Remplacer les outils de base de Linux. Évalué à 1.
Un exemple flagrant est l' ebuild contre spell (gentoo / sourcemage). On peut faire a peu pres la meme chose mais l'expressivité n'est pas vraiment la même...
[^] # Re: Remplacer les outils de base de Linux
Posté par ckyl . En réponse au journal Remplacer les outils de base de Linux. Évalué à 1.
Ou de le faire dans le sens inverse :-)
[^] # Re: Remplacer les outils de base de Linux
Posté par ckyl . En réponse au journal Remplacer les outils de base de Linux. Évalué à 2.
Non la syntaxe d'fstab te donne tout de suite ce que tu cherches. La ligne est simple clair conscise. Ton charabiat d'XML il faut chercher les infos avec les yeux. Un fstab comme le tien avec 25 partitions de montées serait d'une lisibilité folle.
> Ca ne t'apprend pas a te servir du truc, mais tu sais de quoi ca parle au moins, et si il manque une virgule ou autre chose, tu a la dtd
lire une DTD est follement plus amusant que de faire less fstab
1 # /etc/fstab: static file system information.
2 # <file system> <mount point> <type> <,options> <dump> <pass>
vi spécial comme ceux utilisé pour l'édition de la crontab et de sudo
rien ne t'oblige d'utiliser un vi special. C'est juste pour t'eviter de casser ton systeme. Le XML ne t'empechera pas de faire ca.
> En plus, la coloration est directement faite
Heu moi vim me dit quand j'ai tappé
proc /proc proc defaulst (le defaulst est pas en jaune)
Alors que des editeurs de textes qui serait capable de detecter qu'un
<option> defaulst<> c'est plus rare.
> Et enfin, ca faciliterait et éviterait l'éparpillement des outils spécifiques au distrib, en fournissant par exemple un noyau a ceux-ci, qu'il implémenterait en ajoutant leur interface dessus.
Ca c'est un vrai problème pour faire une interface unifiée pour la config.
> Et sinon, a propos de pmk, ya beaucoup de projet qui l'utilise?
Pas enormement c'est jeune et comme tout projet jeune dans ces domaines avoir une dependence contre PMK est pénalisante. CONS et SCONS ont le même problème il me semble.
[^] # Re: Remplacer les outils de base de Linux
Posté par ckyl . En réponse au journal Remplacer les outils de base de Linux. Évalué à 3.
ServerRoot "/opt/apache"
PidFile /opt/apache/logs/httpd.pid
ScoreBoardFile /opt/apache/logs/httpd.scoreboard
Timeout 200
===============================
<?xml version="1.0" encoding="UTF-8"?>
<!-- Do not edit this file, it will be overwritten on instal -->
<apache_config xmlns="http://apache.org/(...)" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance(...)" xsi:schemaLocation="http://apache.org/(...) file:///usr/share/apache/rc.xsd">
<gobalEnvironement>
<ServerRoot>/opt/apache</ServerRoot>
<PidFile>/opt/apache/logs/httpd.pid</PidFile>
<ScoreBoardFile>/opt/apache/logs/httpd.scoreboard</ScoreBoardFile>
</globalEnvironement>
Le XML c'est facile a lire pour les machines, pour les humains bof bof y'a plus sexy
# Re: Remplacer les outils de base de Linux
Posté par ckyl . En réponse au journal Remplacer les outils de base de Linux. Évalué à 7.
Tu apprends l'outil de zero c'est normal. En quoi apache t'as appris quelque chose sur postfix ?
> Un exemple simple serait les fichiers de configurations, qui n'ont absolument pas, et jamais la même syntaxe. Alors oui, c'est normal que shorewall et apache n'est pas les mêmes fichiers de conf, mais quand même, n'y aurait il pas moyen d'unifier cela un peu plus?
L'unification de quoi ?
XML est juste un langage de balisage. Si out les projets utilisaient XML et leur propre DTD tu serais pas tellement plus avancé hormis d'avoir un fichier illisible rempli de < > </ >.
Autrement ce que tu cherches se nomme une base de registre.... :-)
> qui utilise des *.po, des *.mo et des *.gmo, encore une fois dans une logique des plus étranges
Bin c'est pas les GNUs qui ont inventés ca ? :-)
> Un dernier exemple qui me sidère sont les logiciels d'autoconf, qui se révèlent être un beau boxon si on veut initier un projet dessus.
Encore des GNUseries.... va voir du coté de PMK, http://pmk.sourceforge.net/(...)
> chercher de la doc sur internet pour savoir configurer un jabber, le son ou un serveur ftp.
Tu voudrais que ca se configure tout seul ?
> car il y a surement moyen d'unifier tout autour d'une norme maintenant non (xml?)?
Encore une fois uniformiser quoi ? Defini deja clairement le problème et il y aura peut etre une solution.
[^] # Re: Idée du jour
Posté par ckyl . En réponse au journal Idée du jour. Évalué à 1.
A ouai mais non :-)
Le problème est que tu ne sais pas sous quelle forme se présente l'information. Faudrait avoir une analyse semantique tres (trop) poussée.
En fait que tu veux faire ressemble un peu a faire ce que faire un packageur a priori alors qu'un packageur le fait a priori et a posteriori.
Pour ma part, generalement je connais assez bien les dependences basiques des softs donc on commence par faire une première version. Une fois que le truc marche il y a un script shell qui essait de regarder si par hasard j'aurais pas oublié une dep, par exemple parsage de ldd pour un libxml ratée....
Tu peux aussi imaginer un logiciel en c qui fasse un system("perl xxxxx"). Ton programme pour fonctionner a besoin de Perl, mais cette info n'est dispo que dans le INSTALL ou dans le code.
> - Parfois, les fichiers packagés, s'ils existent, sont trop anciens (il y a toujours un décalage entre la sortie de la dernière version stable et celle du package).
C'est le problème d'une distrib binaire, commencer a tout recompiler n'est pas une solution.
> - Souvent, toutes les distribs sont loin d'être réprésentées
> - Si un logiciel est trop "petit", personne ne va s'embêter à faire des packages.
Faux si le logiciel est inutile personne ne va s'embetter. Generalement les packageurs sont curieux, et les applis sympas ne mettent pas longtemps a avoir un package utilisable (je ne dis pas forcement package officiel). Surtout s'il s'agit de quelque de pas enorme, pour sourcemage ou les spells sont tres facile a faire, en 4 minutes je peux te faire un spell installable (je ne parle pas de qualité la :-).
> Quand à lire un fichier INSTALL, je le fais à chaque fois, et je trouve (sincèrement) que 80% d'entre eux sont incomplets ou faux (libs nécessaires erronées ou non listées, etc.)
Dans ce cas basiquement du fait ./configure il t'insulte il te dit qu'il ne peut pas trouver libmachinechose et tu as juste a faire (apt-get install|urpmi|cequetuveux) libmachinchose(-dev ?). C'est le cas simple que ton prog a effectivement une chance de gerer. Mais un utilisateur un tout petit petit peu degourdi ne ferait-il pas exactement le meme chose ? Autrement encore une fois tout ce qu'il va faire c'est foutre le bordel sur sa machine.
> [ mastermind ]
Ton logiciel ne pourra rien contre les logiciels mal packagés. Par exemple on ne peut pas avoir Gnomemeeting 1.0 sur sourcemage pour le moment par ce qu'on est au moins 4 a s'etre peté les dents dessus... Alors qu'en le compilant a la main il n'y a pas de problèmes.
Un truc qui me semble plus interessant que ce que tu comptes faire serait d'adapter portage/sorcery/autre pour qu'il sachent gerer les dependences rpm/deb. C'est a dire de modifier la libdepends par exemple pour qu'il essait d'abord les methodes officielles de la distribution et d'utiliser tout le reste. Et la dessus tu peux facilement faire une interface graphique. Mais ce n'est plus ton logiciel qui fait le boulot des packageurs.
Enfin ce n'est que mon avis :-)
[^] # Re: Rooooooooooooohhh
Posté par ckyl . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 1.
Donc sur un pauvre Athlon 1.2Ghz 40 minutes a tout casser.
[^] # Re: Rooooooooooooohhh
Posté par ckyl . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 1.
Using gcc version: 3.4.0
20040423:0340(+0000) dispel glibc 2.3.3 success
20040423:0347(+0000) cast glibc 2.3.3 success
En effet ca fait dans les 12h....
[^] # Re: Idée du jour
Posté par ckyl . En réponse au journal Idée du jour. Évalué à 1.
tu peux me pointer ce qui te semble etre interessant dans la chose ? J'ai surement raté quelque chose.
# Re: Idée du jour
Posté par ckyl . En réponse au journal Idée du jour. Évalué à 1.
Pour avoir packagé un nombre non negligeable d'applications dans des distros sources je peux te dire qu'il est inconcevable de faire un logiciel qui sache automatiquement tout compiler et gerer les dépendences. Déjà avec les les usines a gazes^W^W^Woutils GNU c'est bien le bordel (regarde des packages comme insight) mais je tu ajoutes a ca tout les softs qui n'utilisent pas les outils GNU et c'est pas réalisable comme projet ( a moins de monter une usines a gaze ^100).
Genre tu as la petite applis du style gtk2-ssh-askpass le spell sourcemage resultant est pour la compilation / installation :
(
sedit "s/gcc/gcc $CFLAGS/" Makefile &&
make &&
prepare_install &&
cp gtk2-ssh-askpass /usr/bin/ &&
if [ ! -e /usr/libexec/ssh-askpass ] ; then
ln -s /usr/bin/gtk2-ssh-askpass /usr/libexec/ssh-askpass
fi
) > $C_FIFO 2>&1
Je te met au défi de retrouver les libs qu'il utilise, et comment construire (le gars devait pas savoir faire de Makefile :-)
De plus comment tu gères les dependences de facon generique ?
Bref ce n'est absolument pas rationel étant donnée que le nombre de types de fichier en entrée est "infini" de même que les formats de sortie.
2/ C'est inutile
Celui qui compile son application doit savoir ce qu'il fait. Autrement qu'il utilise les packages de sa distribution. Je ne vois aucun interet a ce genre de chose. Si le gus est incapble de faire un less INSTALL && faire ce qu'il y a dit dedans je ne vois pas l'interet qu'il pourrait tirer de sa compilation. Hormis tout casser.
Si l'application n'est pas packagée le plus simple est d'envoyer un mail gentil sur la ml de dev de la distribution que tu utilises. Si l'outil interesse quelqu'un tu as de grandes chances d'avoir ton package dans la semaine.
3/ C'est deja fait
Ca s'appelle une distribution source. Et si pour le moment les packageurs n'ont pas été remplacer par des algorithmes il y a peut etre une raison...
Tu reinventes la roue en bordelique et pas très rationel quoi
cf: sourcemage
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par ckyl . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 4.
- changer de distrib
Et la réalité est bien triste pour Debian. Si sortir une version quand elle est prête est louable, ne jamais sortir de version est autre chose. J'ai pas trop suivit l'histoire mais si la modification du contrat social affecte la sortie de la sarge c'est completement con. Le travail a l'air d'etre, presque, achevé. Repousser un truc qui pourrait etre fait pour ce genre de motif est assez risible; qu'est ce qui l'est empêche de sortir une version stable maintenant et une version stable et triée dans 1 ans ? Ce ne me semble par être le genre d'impératif qui justifie de repousser une version majeure d'un produit.
S'amusez a ce genre de chose c'est soit n'en avoir vraiment rien a foutre de ses utilisateurs soit du masochisme.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par ckyl . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 4.
[^] # Re: Si vous étiez riches!
Posté par ckyl . En réponse au journal Si vous étiez riches ..très riches !. Évalué à 1.
Hoho il faut redescendre de votre nuage monsieur
[^] # Re: Traquons les sites webs pourris.
Posté par ckyl . En réponse au journal Traquons les sites webs pourris.. Évalué à 1.
[^] # Re: Mandrake 9.2 je te hais
Posté par ckyl . En réponse au journal Mandrake 9.2 je te hais. Évalué à 1.
[^] # Re: Que ne savons-nous pas ?
Posté par ckyl . En réponse au journal Que ne savons-nous pas ?. Évalué à 1.
Regarde simplement combien sont payer les bons algorithmiciens et ce que peux rapporter un algo polynomial dans certains domaines....
[^] # Re: Ouin, Grsec il m'embête (T_T)
Posté par ckyl . En réponse au journal Ouin, Grsec il m'embête (T_T). Évalué à 2.
Il faut bien entendu faire un lock au boot et empecher chargement de module/access aux disques/mem
[^] # Re: brevets jpeg : plainte contre 31 sociétés
Posté par ckyl . En réponse au journal brevets jpeg : plainte contre 31 sociétés. Évalué à 1.
[^] # Re: ca r0x !
Posté par ckyl . En réponse au journal ca r0x !. Évalué à 1.
C'est donc moi qui ne suit pas près pour le desktop par contre j'ai pas du tout du tout souvenir d'avoir modifié cette option.
En tout cas merci beaucoup
[^] # Re: Pourquoi Linux est-il aujourd'hui si peu utilisé ?
Posté par ckyl . En réponse au journal Pourquoi Linux est-il aujourd'hui si peu utilisé ?. Évalué à 1.
que tout systeme a des erratas et des binaires pour patcher les merdes et les trous de sécu de la release.
> C'est quoi tes lignes absconses à propos de python ?
Un joli exemple d'appli qui leak dans les 1.5 Mo de RAM a l'heure. Et qui donc necessiterait une mise a jour qui demanderait un peu de bande passante pour mettre a jour.
Il me semble que si tu ne veux patcher que ce qui fait "que ton OS se planterait au bout d'une semaine" tu n'as pas 1 Go de download par mois non plus...
[^] # Re: Pourquoi Linux est-il aujourd'hui si peu utilisé ?
Posté par ckyl . En réponse au journal Pourquoi Linux est-il aujourd'hui si peu utilisé ?. Évalué à 1.
Et des fois on aimerai meme un peu plus de mise a jour des packages foireux :
????? yyyyyy 16 0 123m 45m 8236 S 3.2 14.6 147:34.23 python
????? xxxxx 17 0 76020 37m 5608 R 3.9 12.0 98:09.49 python
le premier a 5 jours alors que le deuxieme 2.5 jours...
Mais c'est oublier que windows c'est le mal de dire tout ca.
[^] # Re: Pourquoi Linux est-il aujourd'hui si peu utilisé ?
Posté par ckyl . En réponse au journal Pourquoi Linux est-il aujourd'hui si peu utilisé ?. Évalué à 1.
Bin perso j'eteind l'ecran quand quelqu'un entre dans la pièce ou je me depeche de lancer un joli jeux 3D :-)
[^] # Re: Windows : terrain de jeu des virus
Posté par ckyl . En réponse au journal Windows : terrain de jeu des virus. Évalué à 3.
Donc il suffit de ramener la machine au service informatique du boulot.