Batchyx a écrit 1261 commentaires

Tu confond Pays et Nation. Ce dont tu parle, c'est plus d'une nation avec son histoire, sa langue et sa culture. Les deux sont indépendants. Certaines nations ont été coupées en deux par des frontières (Corée ...), et certains pays regroupent plusieurs nations qui se s'aiment pas beaucoup (notamment un certain plat pays ...).

Exact, C'est quand même idiot que ces imbéciles de programmeurs python n'y aient pas pensé.

Python 3.1.2 (r312:79147, May  8 2010, 16:36:46) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Degage:
...         def __init__(self):
...                 self.__pastouche="lal"
...         def hello(self):
...                 return self.__pastouche
... 
>>> a=Degage()
>>> a.__pastouche
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'Degage' object has no attribute '__pastouche'
>>> a.hello()
'lal'

Et ce n'est pas du tout penser aux utilisateurs (les plus importants pour moi) que de préférer ne rien fournir que de fournir un truc mal fait.

J'ai envie de dire un truc : je ne vais pas parler pour tout les utilisateurs, mais pour moi même.

C'est exactement la raison qui m'a fait quitter windows.

Avoir un système avec lequel 99% des applications ont l'air de marcher, mais sont extrêmement mal intégrées, se font des conflits entre elles, et pareil pour les drivers, j'en ai marre. Si 10 applications plantent une fois sur dix, alors 70% du temps il y en aura une qui plantera, et 70% du temps je serait en rogne.

On dit que "On a pas d'écran bleu sous windows si on a pas des pilotes pourris", mais en attendant, le pilote pourri c'est la seule chose que l'on à pour faire marcher notre matos, et on à pas forcement envie de le changer.

À comparer avec Debian unstable, ou le nombre d'application que j'installe est infiniment plus grand (pourquoi se gêner, ça prend pas de place, on peut installer tout les paquets de Debian Sid sur un disque de 110 Go), et ou le nombre de plantage en 5 ans est largement inférieur à ce que j'ai eu en 1 mois de windows.

Et je doute que je soit le seul a avoir cet avis ou cette expérience.

Oui il à fallu faire des sacrifices. Mais franchement, je regrette pas. J'ai du au départ installer des applications à la main, mais ensuite j'ai vu les applications que j'installais souvent à la main se retrouver dans le dépot debian, j'ai vu le nombre de patch que j'appliquai au noyau diminuer. J'ai vu des projets moins connu que le tiens se retrouver dans le dépot. J'ai même vu des bêtes scripts perls de 50 lignes se faire packager la gueule.

Alors j'arrive pas à expliquer pourquoi tu n'y rentre pas par autre chose que par le fait qu'il y ai personne qui utilise ton logiciel, qu'ils soit chiant à packager ou que ton code est horrible.

Mais en même temps, quand je me met à la place du mainteneur, il arrive sur ton site et il à l'impression d'être sur le site d'une appli pour windows, il arrive sur la page de téléchargement et il voit "Official Release". C'est bizarre, il fait passer des paquets fait maison pour des paquets "officiels" de la distro, ça semble très louche tout ça. C'est peut être pour ça qu'il part en courant.

Mais arrête de croire que c'est aux développeurs de faire des paquets. Ça Ne Marche Pas. Si ça marchait, alors lintian ne serait pas en train de gueuler sur ton .deb.
Déjà que ça ne marche pas sous windows, pas la peine de chercher à reproduire ça sous linux.

Et si je veux contribuer des patches, il faudrai peut être que je teste si je n'ai pas pété ton logiciel avec. Parce que faire un patch sans tester ni connaître le logiciel, j'ai pu faire ça qu'une seule fois. (avec Django je crois)

<quote>On doit avoir un conflit de pensée : de mon point de vue, vaut mieux un paquet mal fait que pas de paquet du tout.</quote>

Mon avis est qu'il n'y a pas qu'avec moi que tu a un conflit de pensée.

Ton raisonnement est valide à petite échelle. Mais à l'échelle d'une distribution, plus on accepte les paquets mal faits, plus on fini par avoir des paquets mal foutu, troués, voire qui font un rm -rf / (oui ça existe, un paquet qui fait un rm -rf $VARIABLE_PAS_DEFINIE/$AUTRE_VARIABLE_PAS_DEFINIE), et avoir un jour un gros problème.

Debian supprime des paquets qui ne sont pas maintenus, alors qu'ils sont utiles. Avoir un paquet mal fait est suffisant pour enlever l'intérêt du système de paquet tout entier.

Pour les patches, j'en proposerait bien, mais pour ça faudrai que j'ai envie d'utiliser ton logiciel. (Je ne sais même pas à quoi il me servirait : connaître le codec d'une vidéo, j'obtient ça avec mplayer, et si j'arrive pas à lire la vidéo, connaître le codec ne m'aidera pas : si le codec existait, alors il serait déjà installé et fonctionnel.)

T'a déjà utilisé lynx pour dire ça ?

(En essayant d'autres alternatives en mode texte, hein ...)

Non le but c'est pas que "les autres fassent les paquets", le but c'est que ce soit les mainteneurs de la distribution qui le fasse. Parce qu'on sait très bien ce qui se passe quand on laisse des développeurs pas consciencieux comme toi le faire :

E: mediainfo: description-starts-with-package-name
E: mediainfo: copyright-contains-dh_make-todo-boilerplate
W: mediainfo: binary-without-manpage usr/bin/mediainfo
E: mediainfo: missing-dependency-on-libc needed by ./usr/bin/mediainfo


Et une autre chose que tu n'a pas l'air de comprendre, c'est que le gestionnaire de paquet est taillé pour la distribution. Si tu essaye de mettre dpkg sur Gentoo ou emerge sur Debian, ça ne pourra pas marcher, sauf à transformer debian en gentoo et inversement.

C'est unstable qui aura des logiciels récents, pas stable ;)

T'est risible à comparer un OS entier avec un codec vidéo.

Et ne prend surtout pas h264 ou HTML comme un bon exemple. du temps ou les téléphones portables n'avaient pas d'écran couleur, jamais HTML n'aurai pu marcher convenablement. On à du créer le WAP à la place.
C'est pareil pour un codec vidéo : Prend un vieux bidule embarqué pas capable de décoder du h264 : ben t'est dans la merde.

Ici on parle d'un OS, un logiciel qui doit s'adapter au matériel (et pas l'inverse, merci HTML et h264)

Quand à RPM et DEB, désolé, mais ça conviens pas à tout le monde, surtout pas aux distributions sources ou à l'embarqué. Les deux font peut être la même chose, mais ça ne convient pas à tout les usages.

Quand au nommage différent, il faudrai peut être se renseigner sur comment les paquets sont nommés. Par exemple sous debian, on considère souvent que 1 bibliothèque = 1 paquet, et le nom du paquet doit contenir le soname de la bibliothèque. Je connais pas la raison exacte, mais à mon avis, ça doit permettre d'éviter des conflits et des dépendances diaboliques si on regroupe trop de bibliothèques en un seul paquet.
Et bien entendu, si on doit changer ça dans Debian, on doit le changer dans toute la distribution, sur toutes les architectures et tout les noyaux. J'imagine pas le bordel.

Alors qu'une distribution source comme gentoo aura plutôt envie de faire correspondre le nom et le contenu du paquet avec le tar.gz d'upstream. Ça fait des choses radicalement différentes : ce que gentoo fait en un paquet (avec des use flags, faut pas les oublier eux aussi), Debian peut le faire en 10.

Et il y a autre chose que tu oublie complètement avec une distribution, c'est la compatibilité et les ABI binaires. Si tu prend un linux 2.6.8 et un 2.6.32, ça marchera pas entre eux. Pareil selon tes versions de libc, ton compilateur et tes options de compilation (par exemple : bibliothèques statiques ou dynamiques ? parfois upstream propose du statique par défaut, et certaines distributions le force en dynamique, pour de bonnes raisons)

Linux n'écoute pas l'utilisateur, blablabla

C'est parfaitement normal. C'est pareil pour Windows et Mac OS X. Ils n'écoutent pas l'utilisateur, ils écoutent le fric. S'il font plus de fric en ayant plus d'utilisateurs, alors seulement ils écouteront l'utilisateur, mais uniquement pour le fric qu'ils représentent. (je suis pas sur qu'une démocratisation de Mac OSX fasse gagner du fric à Apple s'il doit baisser les prix et l'autoriser sur du matos non-Apple)

Le Libre lui il fonctionne pas au fric, mais plutôt aux développeurs, ou aux traducteurs/packageurs, enfin bref, les contribueurs quoi.

L'utilisateur il viens après. S'il faut emmerder les contribueurs en packagant du pas libre, les développeurs en débuggant des pilotes proprios (ah non, c'est vrai j'oubliais, c'est interdit), en leur enlevant la flexibilité et le choix dans leur codage, tout ça pour espérer avoir plus d'utilisateurs, alors on se tire une balle dans le pied. Il ne restera que des utilisateurs, et plus personne pour faire avancer les choses.

Si tu a des moyens qui plaisent au développeurs pour avoir plus de développeurs, alors te gène pas.

Faut arrêter de croire que Debian Unstable doit forcement avoir des logiciels à jour. le but d'unstable est de servir de casse pipe pour testing, qui doit être stabilisé pour devenir stable. Et quand testing se stabilise, unstable ne sert qu'a tester des correctifs pour testing. au final, unstable ~= testing.

Quand squeeze sera sorti, on les aura nos logiciels récents.

Comment veut tu qu'une distro pour ARM en embarqué puisse suivre la même norme qu'une distro pour PC amd64 surpuissant ?

Comment veut tu faire mettre d'accord Debian, qui tourne avec plusieurs noyaux sur plein d'architectures avec une autre distribution qui ne connaît rien d'autre que le Linux sur x86 et amd64 ?

Si le noyau linux est aussi utilisé et aussi portable, c'est bien qu'il est hyperconfigurable, qu'il n'y a pas deux distributions qui le configure pareil. C'est pareil pour les applications, il y a des choix bas-niveau à faire, pas forcement compatibles.

Ce que j'aime bien c'est que tu me prends vraiment pour un blaireau...

Je me répète : tu le fait un peu exprès aussi.

T'est juste en train de me confirmer que pour toi, ne pas installer la dernière distribution """""normale""""" (un bien drôle de mot : il y a des distributions anormales ?!?!? t'attend quoi pour soumettre un bug ?) c'est forcement inutilisable. À croire que les distros spécialement faites pour les vielles machines, ça ne sert à rien, c'est "pas utilisable", et que remplacer gnome par xfce ou autre c'est "se restreindre son usage" (comment tu fait sous windows, avec un WM encore plus pourri ?)

Surtout quand tu mentionne une machine avec 1.2 Ghz, 768 Mo de RAM et disque dur récent comme exemple de "machine complètement inutilisable", alors que c'est ce que j'utilise tout les jours, sans avoir l'impression de forcer ni rien.

Je viens d'essayer Gnome un peu : de base, je constate pas le moindre ralentissement, mis à part qu'il prend sa part de RAM et qu'il se met à swapper dès que je lance mes applis de croisières (plein d'terminaux, 2 firefox, thunderbird/akgregator et autres bidules graphiques). Je pourrai très bien utiliser vlc, oo et thunderbird en même temps sans trop de problème, mis à part que j'aime pas vlc.

Et tout ça sur debian unstable, certainement la distro la moins mise à jour (la preuve, gnome à planté dans l'heure).

Note que j'ai aussi des machines plus puissantes, et que j'ai pas l'impression que ce PC soit "à la traîne" par rapport aux autres. Je connais aussi d'autres personnes qui utilise le même genre de machine, sous Windows XP, alors que c'est trop lourd, et qui n'ont aucun problème pour utiliser ma machine en cas de besoin. C'est pour ça que je te trouve trop restrictif.


Et au passage, awesome est un poil lourd quand on à que 64 Mo de RAM. Il faut un WM qui soit capable d'être temporairement swappé presque entièrement juste le temps qu'une appli lourde s'initialise. Mais on garde pas une machine avec 64Mo de RAM si on est pas un geek pas préssé.

Pour toi, ne pas installer la dernière version d'une distribution "normale" c'est restreindre ton usage ?

Tu a une définition un peu bornée de la "normalité" et de l'"usage classique", bien plus que l'utilisateur de base qui sait très bien rester sous Windows XP, 2000, et même 98 tant ça marche.

Tu le fait un peu exprès aussi.

Ça rame quand tu double clique sur nautilus, c'est normal, nautilus est lent. Ça rame quand tu utilise VLC, c'est normal, VLC c'est lent. Ça rame quand tu utilise Flash, mais le nombre de PC qui fait tourner Flash convenablement, que ce soit sous linux ou sous windows, est ultra-minoritaire. Flash n'est même pas foutu d'être rapide sous Windows, comment voulez vous qu'il soit rapide sous linux ?

C'est sûr que si tu y installe Seven sur ta machine tu ne pourra que dire que "ce n'est pas confortable". À un moment il faut peut être avoir la présence d'esprit qu'il faut utiliser des alternatives plus légères qui n'ont pas les fonctionnalités que tu n'utilise pas.

Mon portable 600 Mhz, 64 Mo de RAM avec une Savage4IX n'utilise que 50-70% du CPU pour lire des flux basse définition avec mplayer (mais l'écran à matrice passive est trop pourri pour regarder une vidéo, il faut utiliser un écran externe)

Et ma machine principale n'a que 266 Mhz de plus que ta machine.

Pareil.

Un portable de gamme "pro bas de gamme" (si si, ça existe, c'est de la gamme pro pas chère) acheté d'occasion, avec un proco 600 Mhz et 64 Mo de RAM que je n'ai même pas upgradé. Mis à part la charnière qui à lâchée deux fois à force d'utiliser mon portable dans les bus et trains

Après avoir constaté que gentoo n'améliore pas les performances, je suis passé sur une debian, mais Awesome c'est un peu trop lourd comme WM, j'ai trouvé que wmii s'en sortait mieux lorsque le système à besoin de swapper.
Sinon pour mon utilisation quotidienne, lynx, vim, irssi, psi/mcabber, gnumeric/abiword, mplayer, dia et ça me va très bien.

Mais c'est un peu dommage, que des logiciels qui auparavant ne posait aucun problème (Openoffice, firefox, gimp) se soient alourdis et qu'il deviens difficile ou impossible de les utiliser. Parfois il existe des alternatives prenant moins de RAM, parfois non (pour gimp par exemple)


Depuis, ma machine principale, aujourd'hui, c'est une tour, mais je ne délaisse absolument pas le portable pour autant.

Manifestement, on ne profite pas de cette "sécurité d'un point de vue technique", peut être qu'elle n'existe pas, ou qu'elle est planquée derrière une fonctionnalité cachée et désactivée.

le minimum de respect est de ne pas insulter les choix différents des autres.

Le Libre, ça implique le droit d'insulter les choix que l'on aime pas, et de prouver qu'on est les meilleurs en implémentant d'autres solutions. Sinon ça sert à rien de faire du libre. Autant retourner sous Windows, ou la licence t'empêche de publier certains benchmarks.

L'effet KDE 4.0 ?

Tout le monde n'a peut être pas envie de débourser 700€ + le prix du jeu juste pour avoir une idée de ce qu'est un jeu récent. Ça deviens uniquement intéressant lorsque tu a besoin d'une machine puissante de toute façon.

Un peu comme le gamer moyen quoi : il joue à des jeux récents seulement lorsqu'il vient de renouveler sa machine, mais il renouvelle pas sa machine uniquement pour jouer.

Ah le format de paquet unique ... ça parait tellement miraculeux ... En attendant que ce miracle (ce cauchemars) arrive, voici comment je verrait la structure du Paquet Unique :

• Le nom du paquet.
• Les dépendances, de 15 types différents : Dépendance forte, Fortement Recommandé, Recommandé, Suggéré, Casse, Entre en conflit lors de l'utilisation, Entre en conflit lors de l'installation, Fourni les fonctionnalités de, Compatible avec, Déprécie, Remplace, Emmerde le développeur de, Permet de compiler, Utilisé par, Doit être de la même version que, Nécessite le redémarrage de, Nécessite le paramétrage de.
• La description du paquet, en 115 langues, avec pour certaines langues, des encodages différents.
• Un lien vers le site web, avec 115 URL différentes si le site web existe en plusieurs langues.
• Lesquelles des 56 architectures qui sont supportées
• La date de compilation, de création du paquet, de mise dans les dépots, de sortie du paquet.
• La taille des programmes une fois extrait
• Les binaires (pour les distros binaires), catégorisés en 30 types, dont Fichier de configuration, Fichier natif exécutable, Librairie dynamique, Librairie statique, Fichier nécessaire pour la compilation, Documentation non-compilée, Documentation compilée, Script, Bytecode compilé
• Les sources (pour les distros sources), catégorisées en 20 types : Entête, Source, Fichier de configuration de compilation, Script de génération de sources, Script de compilation
• Si le paquet contient une locale, la langue de la locale.
• De quoi télécharger les sources (pour les distros téléchargeant les sources directement depuis le site officiel)
• Les versions des compilateurs utilisés pour générer les binaires
• Les patchs pour compiler les sources.
• De quoi configurer les sources (avec l'équivalent des USE flags)
• De quoi compiler les sources.
• Les tarifs selon le type de contrat de support.
• La licence de l'application, avec son type parmi 20 : Domaine public, Licence libre copyleft, Licence libre sans copyleft, Licence opensource propriétaire, Licence propriétaire avec exception opensource pour amateurs ....
• Une liste des 20 SSII qui peuvent ajouter des fonctionnalités.
• Une entrée de changelog, indiquant les bugs corrigés, dans les 20 types de bug trackers existants
• Une liste de matériels supportés ou nécessaires

Alors, vous en pensez quoi ?

Manque à gagner objectif pour l'entreprise lésée, mais pas forcement pour la société tout entière. Mais si le mec avait acheté, alors les 20€ qu'il sortirait de sa poche, ce sont 20 euros qui n'iront pas autre part.

Maintenant, la question est de savoir si on crée plus d'emplois en versant 20€ dans des majors qui passent leur temps à s'engraisser sur le dos des artistes, qu'en versant 20€ dans d'autres produits que les gens achètent à la place.

Et ça, bien entendu, c'est pas facile à faire.

Ce problème existait déjà du temps des grecs. Les paysans restaient sur leurs terres pour garder leurs moutons plutôt que d'aller voter.

Leur solution ? payer un peu les paysans quand ils viennent voter.

Ben... Quand on force le développeur à faire ça pour pouvoir être compatible un peu partout, faut pas s'étonner qu'il le fasse non?

Le développeur ferait mieux de faire le forcing pour mettre son appli dans une distro, distros assez compréhensives sur le sujet, avec des initiatives comme debian mentors ou autre.

C'est ça qui est rigolo : faut pas faire de statique, faut se farcir toutes les distros toutes incompatibles entre elles au niveau packaging.
Le développeur, lui, va voir ailleurs la où l'herbe est meilleure, avec un fabriquant d'OS qui pense un peu plus à lui.

Statique ou pas statique, je vois pas en quoi le problème change. Que tu fasse ton appli en statique ou en dynamique, tu fera de toute façon un paquet ou une archive crade qui marchera que chez toi. Parce que comme tu le dit toi même, ça t'emmerde et tu recherchera absolument pas la qualité. Alors qu'un bon mainteneur saura très bien faire une applis statique qui marchera partout, et qui fonctionnera encore dans 5 ans, parce qu'il saura bidouiller le linkage pour mettre la libc en dynamique, un peu du reste en statique avec des overrides retardés de sections non-résolues (autrement dit, du chinois pour des développeurs) et autres flags mystiques dont nous développeur, on se fout royalement.

Faut pas laisser faire les développeurs pour packager. J'ai déjà vu des programmes avec des makefiles fait à la main, qui font six pieds de longs, qui gère même les dépendances au cas ou les librairies sont remplacées, avec des compilations super complexes, qui naturellement ne marche pas sur ma distrib, alors qu'un petit gcc *.c -lX11 -o appli fonctionnait.

Pas un mot des développeurs ? Même pas celui la ?

Now it's our turn to give back. As of 5/11/10, Aquaria, Gish, Lugaru HD, and Penumbra Overture pledge to go open source.