Je dois dire que je suis un inconditionnel de apt-get. Que dois-je écrire derrière le nom de notre sacro-sainte commande de gestion de paquet pour pouvoir tester ce jeux aux screenshots si prometteurs?
Le problème principal est probablement que la communauté ruby semble ne pas beaucoup donner d'importance à la stabilité des APIs et aux régressions au sein d'une même version majeure. S'ils étaient un peu plus coopératifs avec les distributions (qui ont besoin de la stabilité des APIs pour avoir un packaging efficace) tout serait réglé.
Pour ma part je ne suis pas français, mais en l'occurence je ne crois pas que la France soit peuplée de chômeurs, et il n'est certainement pas non plus nécessaire de se faire naturaliser pour travailler à l'étranger.
C'est le problème principal. On est dans le monde de la facilité, de l'immédiateté et de la paresse (les gens veulent quelque chose maintenant, tout de suite et sans se casser la tête) mais aujourd'hui il est extrêmement plus compliqué d'obtenir ce que l'on veut légalement qu'illégalement.
En Belgique il est par exemple impossible d'obtenir certaines séries en VO sous-titré en VO dans des délais raisonnables. Elles ne sortent qu'en DVD (6 mois après avoir été diffusées en français à la télé, soit avec plus d'un an de retard), avec deux pistes audio (fr / en) et deux ensembles de sous-titres (fr / nl)...
Ben c'est un peu comme toutes les activités subventionnées: tant qu'on te donne du budget tu as tendance à l'utiliser complètement sinon après on va te dire que tu n'as pas besoin d'autant et on va te donner moins.
Il y a énormément de pognon gaspillé dans les tournages, tout simplement parce qu'il y a eu quelques années fastes qui ont permis d'enfler les budgets, et maintenant que le blé se fait plus rare, il est difficile de les réduire...
Après, quand tu vois le chantage au salaire effectué par certains acteurs de séries américaines (je pense par exemple à ce qui s'est dit sur les dernières saisons de Desperate Housewives), tu te dis que ça doit être quand même bien rentable sinon ils jetteraient l'éponge ou changeraient d'acteurs (retirer un acteur d'une série ça se fait tout le temps, y'a qu'à voir la saison 9 de "Mon oncle Charlie", sans Charlie).
Pour les appareils photos, ça existe et ça s'appelle le RAW.
Pour une image diffusée sur le web, cela n'a aucun intérêt je pense, ce serait même contre-productif dans la mesure ou toute informatiion additionelle doit être codée et induira donc inévitablement une pénalité en terme de poids de l'image compressée. Et si tu dis que tu penses conserver 8 bits par couleur, alors c'est contre-productif parce que tu vas perdre de la précision dans les couleurs visibles...
C'est idiot, rien ne t'empêche d'utiliser les applications Gnome et la plateforme Glib/Gtk avec un autre WM, et d'autres programmes.
À tout péter, ça veut dire que tu dois maintenir l'ensemble suivant:
gnome-panel
gnome-applets
nm-applet
alacarte
Il serait aussi de bon ton de suivre le développement d'autres trucs comme gnome-session pour s'assurer que ça reste compatible, et éventuellement créer alors un mate-session si ça ne l'est plus.
Tout maintenir, c'est un travail colossal, et c'est faire le travail deux fois.
Ça reste une mauvaise approche. Les contributeurs sont rares, et Gnome a déjà assez de mal à trouver des gens pour bosser sur la plateforme. Donc il serait sans doute plus intéressant pour tout le monde de reprendre la maintenance de gnome-panel et gnome-applets quite à en faire une alternative à gnome-shell.
Mais systemd est-il une avancée réelle ? Sur les serveurs je crois que le système init ne nécessite pas vraiment de remplacement : il fonctionne, il est simple et il n'y a pas vraiment besoin de démarrage en parallèle.
Parfois les services sont un peu buggés et perdent des processus suite à des événements inattendus:
Un script CGI qui forke deux fois.
Un démon avec des child processes dont le process principal meurt.
Un démon qui forke deux fois inconditionnellement et ne gère pas les PIDfiles.
etc.
systemctl restart $service tue ces processus paumés, mais ce n'est généralement pas le cas du script d'init old-school associé au service, ou en tout cas ce n'est pas faisable de façon fiable sans modifier le démon en lui-même (et encore, un bug peut toujours arriver).
Le "cacheage" de ce qui est envoyé sur les sockets des démons qui sont en train de redémarrer ça peut aussi être vachement utile sur un serveur.
Donc tu as raison, on se fout de démarrer les services en parallèle, mais pour d'autres choses systemd ça peut être vraiment sympa.
Petite note: je suis un heureux utilisateur de Debian et de Network Manager depuis au moins quatre ans et je n'ai jamais eu de problèmes pratiques. Tout au plus Network Manager se contrefiche de ce qu'il y a dans /etc/network/interfaces, et encore, cela ne m'a pas plus choqué que cela. Que devrait-il faire? placer un inotify sur /etc/network/interfaces?
Je n'ai aucune idée de ce que fait NM sous fedora quand on change le fichier de config réseau.
ses utilisateurs savent qu'écrire "!#/bin/sh" signifie "ne pas tester le script uniquement avec zsh, mais avec un shell purement POSIX", contrairement à la majorité des utilisateurs de bash.
Tout simplement parce que leur shell par défaut (/bin/sh) reste souvent bash, et que l'utilisation de zsh reste suffisemment confidentielle pour que s'ils utilisent des zshismes dans leur script, quelqu'un va vite s'en rendre compte.
Il y a peu, bash était le shell par défaut de toutes les distributions linux majeures, mais avec Debian qui utilise dash, par exemple, ça commence à changer... C'est un peu comme les gens qui faisaient des sites web pour IE6 quand il avait 95% de PDM.
filtrer selon certains critères (GREP ou AWK) comme la date, le programme, le client, etc., pour extraire l'information souhaitée
Tu ne fais que reformuler la même chose que moi avec d'autres critères, pour lesquels l'analyse des fichiers log est tout aussi inefficace.
Le bonne solution à ce problème est d'embaucher un vrai admin système.
Oui, parce que le meilleur admin système du monde est capable de prévoir qu'un relai va déconner à un certain moment et remplir les logs à vitesse grand V, sans monitorer la taille de ses fichiers de logs en permanence ?
Par ailleurs, parfois (genre, en cas de machines hostées chez un client) on n'a pas un controle total sur tout ce qui peut se passer en dehors de sa propre sphère d'influence.
rsyslog ne fournit aucun moyen de contrôle et de limitation de la taille des fichiers, et c'est un réel problème, car remplir une partition est un bon moyen de provoquer un DoS. Peut-être que syslog ne pose pas de problème particulier en opérations courantes, mais quand un problème se présente c'est un gros problème. D'ailleurs je citais ici d'un cas qui m'est arrivé, mais il y a une autre façon très simple de faire générer à syslog des gigaoctets de logs: le flood sur le port 514.
Sur FreeBSD avec syslogd, on peut, par configuration et avec l'aide de logrotate forcer une rotation quand un fichier dépasse une certaines taille.
Je peux le faire sous linux aussi avec rsyslog, mais c'est une configuration relativement compliquée qui devrait être très simple vu le risque potentiel. En fait, ce devrait être fait par défaut et être éventuellement un opt-out.
# Packagés dans les distros ?
Posté par nud . En réponse à la dépêche Un pas de plus pour 0 A.D.. Évalué à 0.
Je dois dire que je suis un inconditionnel de apt-get. Que dois-je écrire derrière le nom de notre sacro-sainte commande de gestion de paquet pour pouvoir tester ce jeux aux screenshots si prometteurs?
[^] # Re: Mmmh
Posté par nud . En réponse à la dépêche Hébergez vos projets avec Gitlab. Évalué à 2.
Le problème principal est probablement que la communauté ruby semble ne pas beaucoup donner d'importance à la stabilité des APIs et aux régressions au sein d'une même version majeure. S'ils étaient un peu plus coopératifs avec les distributions (qui ont besoin de la stabilité des APIs pour avoir un packaging efficace) tout serait réglé.
[^] # Re: Menu Global
Posté par nud . En réponse au journal La fin de la barre de menu?. Évalué à 2.
Je sais qu'avec gnome 2.4 je masquais déjà la barre de menu. Vu qu'il y a eu 15 releases entre les deux ça doit faire 7 ans et demi au moins, donc.
[^] # Re: Pas encore au niveau de VLC
Posté par nud . En réponse à la dépêche GStreamer : bientôt la version 1.0. Évalué à 1.
Pour info c'était de l'humour.
Pour ma part je ne suis pas français, mais en l'occurence je ne crois pas que la France soit peuplée de chômeurs, et il n'est certainement pas non plus nécessaire de se faire naturaliser pour travailler à l'étranger.
[^] # Re: Pas encore au niveau de VLC
Posté par nud . En réponse à la dépêche GStreamer : bientôt la version 1.0. Évalué à -1.
Ben la France on l'aime ou on la quitte, si j'ai bien compris.
[^] # Re: .
Posté par nud . En réponse au journal Les représentants du cinéma et de la télé se plaignent encore.. Évalué à 2.
C'est le problème principal. On est dans le monde de la facilité, de l'immédiateté et de la paresse (les gens veulent quelque chose maintenant, tout de suite et sans se casser la tête) mais aujourd'hui il est extrêmement plus compliqué d'obtenir ce que l'on veut légalement qu'illégalement.
En Belgique il est par exemple impossible d'obtenir certaines séries en VO sous-titré en VO dans des délais raisonnables. Elles ne sortent qu'en DVD (6 mois après avoir été diffusées en français à la télé, soit avec plus d'un an de retard), avec deux pistes audio (fr / en) et deux ensembles de sous-titres (fr / nl)...
[^] # Re: marge = coût de vente - coût d'acquisition
Posté par nud . En réponse au journal Les représentants du cinéma et de la télé se plaignent encore.. Évalué à 2.
Ben c'est un peu comme toutes les activités subventionnées: tant qu'on te donne du budget tu as tendance à l'utiliser complètement sinon après on va te dire que tu n'as pas besoin d'autant et on va te donner moins.
Il y a énormément de pognon gaspillé dans les tournages, tout simplement parce qu'il y a eu quelques années fastes qui ont permis d'enfler les budgets, et maintenant que le blé se fait plus rare, il est difficile de les réduire...
Après, quand tu vois le chantage au salaire effectué par certains acteurs de séries américaines (je pense par exemple à ce qui s'est dit sur les dernières saisons de Desperate Housewives), tu te dis que ça doit être quand même bien rentable sinon ils jetteraient l'éponge ou changeraient d'acteurs (retirer un acteur d'une série ça se fait tout le temps, y'a qu'à voir la saison 9 de "Mon oncle Charlie", sans Charlie).
[^] # Re: 5 minutes ought to be enough for anybody
Posté par nud . En réponse au journal L'édition des commentaires sur LinuxFR, ou pas ?. Évalué à 2.
Ça invalidera tous les commentaires des gens qui ont relevé la faute!
[^] # Re: Pas encore au niveau de VLC
Posté par nud . En réponse à la dépêche GStreamer : bientôt la version 1.0. Évalué à 1.
L'auteur de Totem est français aussi.
[^] # Re: Pas encore au niveau de VLC
Posté par nud . En réponse à la dépêche GStreamer : bientôt la version 1.0. Évalué à 1.
J'ai souvent eu des fichiers qui se lisaient pas (souvent, ils restent blo à un moment donné) mais je n'ai jamais eu de segfault.
[^] # Re: Même erreur que trinity ?
Posté par nud . En réponse à la dépêche MATE, fourchette de GNOME 2. Évalué à 2.
Ce n'est pas forcément vrai. Un programme qui reste quelques années sans maintenance a tendance à péricliter.
[^] # Re: Format d'image ultime
Posté par nud . En réponse au journal WebP, le format d'images ultime. Évalué à -10.
Pour les appareils photos, ça existe et ça s'appelle le RAW.
Pour une image diffusée sur le web, cela n'a aucun intérêt je pense, ce serait même contre-productif dans la mesure ou toute informatiion additionelle doit être codée et induira donc inévitablement une pénalité en terme de poids de l'image compressée. Et si tu dis que tu penses conserver 8 bits par couleur, alors c'est contre-productif parce que tu vas perdre de la précision dans les couleurs visibles...
[^] # Re: Pourquoi un fork complet
Posté par nud . En réponse à la dépêche MATE, fourchette de GNOME 2. Évalué à 10.
C'est idiot, rien ne t'empêche d'utiliser les applications Gnome et la plateforme Glib/Gtk avec un autre WM, et d'autres programmes.
À tout péter, ça veut dire que tu dois maintenir l'ensemble suivant:
Il serait aussi de bon ton de suivre le développement d'autres trucs comme gnome-session pour s'assurer que ça reste compatible, et éventuellement créer alors un mate-session si ça ne l'est plus.
Tout maintenir, c'est un travail colossal, et c'est faire le travail deux fois.
[^] # Re: Même erreur que trinity ?
Posté par nud . En réponse à la dépêche MATE, fourchette de GNOME 2. Évalué à 8.
Ça reste une mauvaise approche. Les contributeurs sont rares, et Gnome a déjà assez de mal à trouver des gens pour bosser sur la plateforme. Donc il serait sans doute plus intéressant pour tout le monde de reprendre la maintenance de gnome-panel et gnome-applets quite à en faire une alternative à gnome-shell.
Après tout, sawfish existe toujours.
[^] # Re: Il fallait bien
Posté par nud . En réponse à la dépêche MATE, fourchette de GNOME 2. Évalué à 5.
Non, ils risquent plutôt de jeter l'éponge vu l'ampleur de la tâche et la façon bizarre tendance inefficace avec laquel ils l'abordent.
[^] # Re: Il fallait bien
Posté par nud . En réponse à la dépêche MATE, fourchette de GNOME 2. Évalué à 9.
Dans six mois on en reparlera.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par nud . En réponse au journal Lennart casse les logs!. Évalué à 1.
Toutafé.
[^] # Re: systemd
Posté par nud . En réponse au journal Lennart casse les logs!. Évalué à 6.
Ben si, avec dmix.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par nud . En réponse au journal Lennart casse les logs!. Évalué à 6.
Parfois les services sont un peu buggés et perdent des processus suite à des événements inattendus:
systemctl restart $service tue ces processus paumés, mais ce n'est généralement pas le cas du script d'init old-school associé au service, ou en tout cas ce n'est pas faisable de façon fiable sans modifier le démon en lui-même (et encore, un bug peut toujours arriver).
Le "cacheage" de ce qui est envoyé sur les sockets des démons qui sont en train de redémarrer ça peut aussi être vachement utile sur un serveur.
Donc tu as raison, on se fout de démarrer les services en parallèle, mais pour d'autres choses systemd ça peut être vraiment sympa.
[^] # Re: Et après ?
Posté par nud . En réponse au journal Lennart casse les logs!. Évalué à 5.
le D de dash, il veut dire Debian.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par nud . En réponse au journal Lennart casse les logs!. Évalué à 4.
Encore faut-il pouvoir trouver des indices sur l'attaque en question. Maintenant on peut:
[^] # Re: Point de vue rétro-actif de noob.
Posté par nud . En réponse au journal Lennart casse les logs!. Évalué à 2.
Petite note: je suis un heureux utilisateur de Debian et de Network Manager depuis au moins quatre ans et je n'ai jamais eu de problèmes pratiques. Tout au plus Network Manager se contrefiche de ce qu'il y a dans /etc/network/interfaces, et encore, cela ne m'a pas plus choqué que cela. Que devrait-il faire? placer un inotify sur /etc/network/interfaces?
Je n'ai aucune idée de ce que fait NM sous fedora quand on change le fichier de config réseau.
[^] # Re: Point de vue rétro-actif de noob.
Posté par nud . En réponse au journal Lennart casse les logs!. Évalué à 1.
Rien n'empêcherait le développement d'un backend 'interfaces-file' similaire au backend keyfile.
[^] # Re: Et après ?
Posté par nud . En réponse au journal Lennart casse les logs!. Évalué à 0.
Tout simplement parce que leur shell par défaut (/bin/sh) reste souvent bash, et que l'utilisation de zsh reste suffisemment confidentielle pour que s'ils utilisent des zshismes dans leur script, quelqu'un va vite s'en rendre compte.
Il y a peu, bash était le shell par défaut de toutes les distributions linux majeures, mais avec Debian qui utilise dash, par exemple, ça commence à changer... C'est un peu comme les gens qui faisaient des sites web pour IE6 quand il avait 95% de PDM.
[^] # Re: Problèmes de Syslog
Posté par nud . En réponse au journal Lennart casse les logs!. Évalué à 2.
Tu ne fais que reformuler la même chose que moi avec d'autres critères, pour lesquels l'analyse des fichiers log est tout aussi inefficace.
Oui, parce que le meilleur admin système du monde est capable de prévoir qu'un relai va déconner à un certain moment et remplir les logs à vitesse grand V, sans monitorer la taille de ses fichiers de logs en permanence ?
Par ailleurs, parfois (genre, en cas de machines hostées chez un client) on n'a pas un controle total sur tout ce qui peut se passer en dehors de sa propre sphère d'influence.
rsyslog ne fournit aucun moyen de contrôle et de limitation de la taille des fichiers, et c'est un réel problème, car remplir une partition est un bon moyen de provoquer un DoS. Peut-être que syslog ne pose pas de problème particulier en opérations courantes, mais quand un problème se présente c'est un gros problème. D'ailleurs je citais ici d'un cas qui m'est arrivé, mais il y a une autre façon très simple de faire générer à syslog des gigaoctets de logs: le flood sur le port 514.
Je peux le faire sous linux aussi avec rsyslog, mais c'est une configuration relativement compliquée qui devrait être très simple vu le risque potentiel. En fait, ce devrait être fait par défaut et être éventuellement un opt-out.