As-tu contacté Radio France? Peut-être ne sont-ils pas opposés à ton "travail". Peut-être peux-tu expliquer que c'est une initiative temporaire pour répondre à un "manque" et que dès que RF fournira un flux ogg, tu supprimeras ton flux car il n'a plus de raison d'être.
Connais-tu l'avis de RF sur ton initiative.
Le file sélector actuel me convient. Il n'y a vraiment pas d'urgence ici. C'est pas la rolls des file selectors, mais elle marche et fait son boulot. Ce qui est normal vu ce qu'on lui demande...
Je ne comprend pas où est le problème. Les applis sont rapidement passées de gtk 1 à gtk 1.2 car il n'y avait pas de différences significatives. gtk 2 est une grosse évolution de gtk 1, comme Gnome 2 est une grosse évolution de Gnome 1.4.
Si des applis ne sont pas protées sous Gnome 2 c'est "grace" au free software qui ne t'oblige pas à monter de version.
Le question est :
- Gnome doit-il évoluer et casser des API quite à rendre le portage difficile ou "ne rien faire".
Ce que vit Gnome actuellement, est déjà arrivé :
- cohabitation win16 win32
- cohabitation OSS alsa
- cohabitation mac OS X avec le mac OS classique
- cohabitation libc6 et glibc2
- etc...
C'est comme ça pour toute les évolutions majeures.
Et que pense le développeur d'appli ?
Il ne disent pas les modification dans Gtk/Gnome 2 sont nulles, on restent sous Gtk 1. Ils disent généralement, "ya pas le feux", "plannifier pour la futur version majeur", etc...
Et je ne vois pas de nouvelles applis qui sont basées sur gtk1. Elles sont baséee sur gtk2 se qui montre que gtk2 apportent des évolutions appréciées par rapport à gtk1.
Faire cohabiter Gnome 1 et Gnome 2 est un plus pour les développeurs d'applis. Il n'y a pas d'obligations.
Juste un petit exemple pour enregistrer
$ at -f enreg 19:59
warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh
job 14 at 2003-03-10 19:59
$ cat enreg
#!/bin/bash
wget http://unix.rulez.org:8888/fr-inter.ogg(...) &
sleep 3600
ps x --cols 1000 | grep "wget http://unix.rulez.org:8888/fr-inter.ogg(...)" | cut -b 1-6 | xargs kill
> Mais sinon ? Quelles alternatives ?
L'alternative pour l'alternative...
La première question est pourquoi prendre quelque chose d'alternatif. Si c'est pour des raisons de sécurité, bind est fort correcte ses dernières années et comme le dit matiasf plus haut, meilleur que beaucoup d'autres projets. Si c'est pour d'autres raisons... pourquoi pas.
C'est repousser le problème. On finit toujours par une fonction C. Ce qui compte c'est la réutilisation du code, diminuer le nombre de ligne de code pour que les audites soit efficace. Et php, perl, etc... ont aussi épisodiquement des trous de sécurité.
Je ne vois rien d'anormal. C'était pour dire qu'il est bon de connaitre la méthode manuelle qui n'a pas de restriction et est aussi gratuite.
J'ai aussi apt-get mais les mirrors ne sont pas encore à jours. En attende 24 heures un apt-get upgrade doit faire marcher sans problème.
Au-dessus, tu ne parles pas d'une utilisation sur serveur anémque niveau place disque. Et maintenant tu vomis sur KDE, Debian, etc...
Mais je suis enchanté de savoir qu'une slackware s'installe sur un libretto 100Ct sans cdrom avec son floppy au bios foireux. C'est vrai que les autres distribes te permettent "seulement" d'installer depuis le CD-ROM, un DVD, le disque dur, disquette et le réseau, et certains offrent des possibilités d'installation et configuration automatique.
Mais je vai conseiller slackware à ceux qui ont un libretto.
Sur un serveur il faut X11 même s'il tourne pas. En cas de crise, ça permet, entre autre, de butiner des sites de documentation, de ce connecter au routeur via http, etc...
Et ça coûte moins cher que d'acheter une bécane pour aller sur le web car il n'y a pas de serveur X11 sur le serveur pour économiser sur le prix des disques dures.
C'est les programmes les plus utilisés qui sont le plus audité. Et c'est les programme les plus complexe/puissant qui sont le plus sujet au trou de sécurité. Rien de nouveau.
Sinon, faut pas psychoter, d'après redhat, la faille est difficile à exploiter. Mais c'est pas une raison pour trainer :-)
J'ai fait un up2date, comme d'hab (suis sous redhat) :
Error Message:
Demo service for serveur 1002052815 limited due to high load
Error Class Code: 51
Error Class Info:
Demo service currently disabled due to high load. If you would like
to see Red Hat's policies on Demo service, or find out how you can
purchase a subscription service and receive priority download access,
please go to http://rhn.redhat.com/preview/index.pxt(...)
Le temps de lancement d'une appli, est lié au disque dure. Un petit hdparm (avec précaution) peut améliorer les choses comme le paramétrage de la vm fait par les distributeurs. L'utilisation de raid0 strippé, raid 5 etc est aussi un plus avec plusieurs disques. Le plus efficace étant d'ajouter de la ram pour "taper" le plus souvent possible dans le cache.
Conclusion :
Mandrake Linux 9.1 will continue the tradition of "swiss-knife" Mandrake distributions by being equally usable on notebooks, small/medium servers and desktop machines (and even Macs - check my other article). But this RC1 is not ready yet for the majority of new Mandrake Linux users: it has too many small bugs and rough edges.
C'est trop pour une rc. Mais totalement normal pour une beta.
[^] # Re: Euh... | c'est illégal?
Posté par ptit_tux . En réponse à la dépêche Un nouveau stream d'OGG de France Inter. Évalué à 7.
[^] # Re: «How GNOME became LAME»
Posté par ptit_tux . En réponse à la dépêche «How GNOME became LAME». Évalué à 6.
[^] # Re: «How GNOME became LAME»
Posté par ptit_tux . En réponse à la dépêche «How GNOME became LAME». Évalué à 10.
Si des applis ne sont pas protées sous Gnome 2 c'est "grace" au free software qui ne t'oblige pas à monter de version.
Le question est :
- Gnome doit-il évoluer et casser des API quite à rendre le portage difficile ou "ne rien faire".
Ce que vit Gnome actuellement, est déjà arrivé :
- cohabitation win16 win32
- cohabitation OSS alsa
- cohabitation mac OS X avec le mac OS classique
- cohabitation libc6 et glibc2
- etc...
C'est comme ça pour toute les évolutions majeures.
Et que pense le développeur d'appli ?
Il ne disent pas les modification dans Gtk/Gnome 2 sont nulles, on restent sous Gtk 1. Ils disent généralement, "ya pas le feux", "plannifier pour la futur version majeur", etc...
Et je ne vois pas de nouvelles applis qui sont basées sur gtk1. Elles sont baséee sur gtk2 se qui montre que gtk2 apportent des évolutions appréciées par rapport à gtk1.
Faire cohabiter Gnome 1 et Gnome 2 est un plus pour les développeurs d'applis. Il n'y a pas d'obligations.
# Enregistrement
Posté par ptit_tux . En réponse à la dépêche Un nouveau stream d'OGG de France Inter. Évalué à 10.
$ at -f enreg 19:59
warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh
job 14 at 2003-03-10 19:59
$ cat enreg
#!/bin/bash
wget http://unix.rulez.org:8888/fr-inter.ogg(...) &
sleep 3600
ps x --cols 1000 | grep "wget http://unix.rulez.org:8888/fr-inter.ogg(...)" | cut -b 1-6 | xargs kill
Quelqu'un a mieux ?
PS : à usage privé !
[^] # Re: Un nouveau stream d'OGG de France Inter
Posté par ptit_tux . En réponse à la dépêche Un nouveau stream d'OGG de France Inter. Évalué à 10.
http://www.vorbis.com/faq.psp#bugs(...)
Quel est la version de vorbis utilisé par le flux ?
# L'analyse Linux Weekly News
Posté par ptit_tux . En réponse à la dépêche SCO lance des poursuites contre IBM. Évalué à 7.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par ptit_tux . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 5.
- "We are told that exploiting this problem is particularly difficult, but it is theoretically possible."
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par ptit_tux . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 5.
L'alternative pour l'alternative...
La première question est pourquoi prendre quelque chose d'alternatif. Si c'est pour des raisons de sécurité, bind est fort correcte ses dernières années et comme le dit matiasf plus haut, meilleur que beaucoup d'autres projets. Si c'est pour d'autres raisons... pourquoi pas.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par ptit_tux . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 6.
[^] # Re: Clair que ça va troller
Posté par ptit_tux . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 3.
[^] # Re: Ooops
Posté par ptit_tux . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 10.
J'ai aussi apt-get mais les mirrors ne sont pas encore à jours. En attende 24 heures un apt-get upgrade doit faire marcher sans problème.
[^] # Re: Clair que ça va troller
Posté par ptit_tux . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 4.
Mais je suis enchanté de savoir qu'une slackware s'installe sur un libretto 100Ct sans cdrom avec son floppy au bios foireux. C'est vrai que les autres distribes te permettent "seulement" d'installer depuis le CD-ROM, un DVD, le disque dur, disquette et le réseau, et certains offrent des possibilités d'installation et configuration automatique.
Mais je vai conseiller slackware à ceux qui ont un libretto.
Sur un serveur il faut X11 même s'il tourne pas. En cas de crise, ça permet, entre autre, de butiner des sites de documentation, de ce connecter au routeur via http, etc...
Et ça coûte moins cher que d'acheter une bécane pour aller sur le web car il n'y a pas de serveur X11 sur le serveur pour économiser sur le prix des disques dures.
# Re: Faille de sécurité importante dans Sendmail
Posté par ptit_tux . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 10.
C'est les programmes les plus utilisés qui sont le plus audité. Et c'est les programme les plus complexe/puissant qui sont le plus sujet au trou de sécurité. Rien de nouveau.
Sinon, faut pas psychoter, d'après redhat, la faille est difficile à exploiter. Mais c'est pas une raison pour trainer :-)
# Ooops
Posté par ptit_tux . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 10.
Error Message:
Demo service for serveur 1002052815 limited due to high load
Error Class Code: 51
Error Class Info:
Demo service currently disabled due to high load. If you would like
to see Red Hat's policies on Demo service, or find out how you can
purchase a subscription service and receive priority download access,
please go to http://rhn.redhat.com/preview/index.pxt(...)
Retour sur la methode manuelle qui marche.
[^] # Re: Clair que ça va troller
Posté par ptit_tux . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 9.
quelques ldd
evolution : 46
gnucash : 51
vimx : 23
xemacs : 37
galeon : 49
Avec la complexification actuelle, j'ai besoin d'aide...
Unix, ce n'est plus noyau => libc => libx11. Heureusement...
[^] # Re: Slackware 9.0-rc1
Posté par ptit_tux . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 5.
[^] # Re: Slackware 9.0-rc1
Posté par ptit_tux . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 9.
Ça n'apporte rien en légergé mais en vitesse uniquement. Et il n'y a aucun gain sur les données (allocation mémoire, pile, etc...).
[^] # Re: Slackware 9.0-rc1
Posté par ptit_tux . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 10.
http://www.distrowatch.com/dwres.php?resource=review-mandrake(...)
Conclusion :
Mandrake Linux 9.1 will continue the tradition of "swiss-knife" Mandrake distributions by being equally usable on notebooks, small/medium servers and desktop machines (and even Macs - check my other article). But this RC1 is not ready yet for the majority of new Mandrake Linux users: it has too many small bugs and rough edges.
C'est trop pour une rc. Mais totalement normal pour une beta.