#3588 a écrit 2279 commentaires

Va faire du couper/coller entre un tableur et un traitement de texte sans composants, pour voir.

Tu n'as pas l'air de lire, et comme par hasard tu ne cites pas les passages contenant les réponses...

J'ai parlé de la même appli (ou ensemble d'applications). La même chose donc pour l'utilisateur, par définition.

A programmer, évidemment qu'on va vouloir le faire avec des composants (dans le cas d'applications graphiques) si jamais on a un tel besoin de couper/coller. Je n'ai jamais remis en cause leur utilité. Je ne parle ici, que de tes exemples, qui sont de mauvaises comparaisons.

Non, ça n'est pas plus simple, même dans les cas que tu cites (cf. mon autre réponse).

Pour dire qu'on préfère son propre viewer html (ne nécessitant pas de retour) plutot que le composant, il suffit d'un fork comme tu l'as dit, et d'une variable dans un fichier de conf ou dans l'environnement. Je parle des cas où ceci suffit. Ca reste plutot simple.

Et même si ça l'était, avoir 2 solutions complètement différentes, une pour un problème général et l'autre pour un cas particulier du même problème, complique inutilement les choses.

2 solutions différentes apportent avant tout du choix. Ensuite si leur coexistence est impossible, faut faire des choix, par exemple en faveur des composants si le modèle est compliqué.

En tous cas il ne s'agit pas vraiment du même problème, puisque celui des composants concerne la communication et l'interaction entre ces composants. Pour un viewer html c'est juste du lancement d'application externe...

Plus simple, vraiment ? Il faut [bla bla]

J'ai parlé des cas simples, qui existent, là tu cherches déja à compliquer. Pour un mail (je reprends l'exemple de mutt) il va certainement chercher $EDITOR, et ajoute le nom de son fichier temporaire. Pas compliqué.

S'il y a besoin de plus compliqué (on commence à sortir de ce dont je parlais) eh bien tu n'as qu'à considérer que l'utilisateur est trop exigeant et que ce sera à lui de fournir ces infos, dans un fichier de conf, dans un tab de conf, n'importe où, peu importe.

Regarde par exemple les front-ends aux logiciels de gravure où il faut tout spécifier. Le front-end n'a rien à supposer. Ca peut sembler compliqué à l'utilisateur, mais vu que la solution par défaut sera d'utiliser les composants, il n'y touchera que s'il y tient.

Le framework unifie mais restreint. C'est une solution.

Trouve-moi un utilisateur "normal" (ie pas un geek) qui se préoccupe de se genre de détail, et on en reparle.

C'est du même niveau que quand les pro-Windows expliquent qu'un utilisateur normal n'a pas à choisir son wm. Dans la mesure où on peut toujours lui en mettre un par défaut, un qui soit user-friendly, il n'y a aucune raison de critiquer l'existence des autres, chacun a la possibilité de choisir. Si les logiciels libres s'étaient basés sur ton utilisateur dit "normal", le bureau serait un clone de celui de Windows, il n'y aurait aucune variété, aucune adaptation possible à l'utilisateur.

Oui, les deux solutions peuvent co-exister, il reste bien quelques fois où un simple fork() fait l'affaire, mais bon... au final pas tant que ça.

Mais il n'y a que sur ces cas là que je regrette l'inexistence de l'alternative... C'est très peu comparé à l'ensemble des utilisations des composants, oui, je l'ai dit, mais ça peut aussi être très pratique...

J'ai dit pour l'utilisateur, pas pour le développeur. L'utilisateur ne peut pas faire avec la console texte tout ce qu'il peut faire en mode graphique.
Par contre avec ou sans composants, aucune différence de son coté, c'est du coté du développement de l'application qu'ils apportent beaucoup.
La meme appli peut être réalisée avec ou sans composants, ce sera seulement beaucoup plus simple de la réaliser avec des composants. Coté utilisateur ça ne change rien (à part la disponibilité, puisque c'est plus simple à développer), mais ces avantages (certains) ne sont en aucun cas comparables aux exemples sans X11 que tu donnes.

> > et sont même a priori plus simples à implémenter

> Non, justement.

Si. C'est le cas de tout ce qui concerne de l'affichage sans avoir besoin d'un retour. Lancer un navigateur avec une doc html, un viewer pdf, etc. Même récupérer un texte créé par un autre programme n'est pas si compliqué pourvu qu'on ait bien sur aucune exigence d'interaction lors de l'édition.

C'est peut-etre des cas limités par rapport à l'étendue des possibilité des composants, mais ils existent, et l'implémentation est extrêmement simple. Proposer les deux solutions ne coûterait rien. En imposant une solution, l'aspect modulaire des composants apparait peut-etre pour le développeur, mais certainement pas pour l'utilisateur qui se retrouve avec quelque chose de bien moins configurable.

Et alors ? Ça ne veut pas dire qu'on a pas trouvé mieux depuis. Les composants sont précisément une amélioration de ce principe.

Faudrait lire un petit peu au-delà de la première phrase, j'ai bien dit que les composants
- étaient une amélioration,
- qu'ils pouvaient être indispensables,
mais que dans les cas où ils ne le sont pas il est dommage d'imposer une solution quand
- une autre solution aussi simple existe
- l'utilisateur peut préférer cette autre solution (gout personnel, légereté de la solution, etc.)
- les deux solutions peuvent coexister

> > Que je sache, on a un système qui tourne très bien sans, non ?

> arf, le bon vieil argument anti-progessiste :)

Tu vas bien vite en affirmant qu'il s'agit de progrès. Le progrès c'est des choses possibles en plus, pas en moins.

Si je reprends l'exemple de l'affichage de PDF, que quelqu'un a donné, je ne trouve pas ça un progrès qu'un logiciel décide à ma place quel moteur d'affichage va être utilisé.

C'est comme l'apport du graphique : ça facilite peut-être énormément, et il y a beaucoup d'applications où c'est même indispensable et plus ergonomique, mais ce n'est pas une raison pour abandonner la commande en ligne quand celle-ci peut exister. Dans ce cas, rien de tel pour utiliser le logiciel en automatique, dans un script, si on n'a pas X, ou même si on préfère. Qu'un logiciel propose la CLI et la GUI quand il n'y a pas de raison de n'avoir que la seconde, ça c'est un progrès. Qu'il supprime la première sans raison, c'est plus discutable.

Les composants devraient faire la même chose : s'ils sont vraiment indispensable parce qu'il faut de la communication entre composants, très bien, les utiliser, c'est l'évidence même ; mais si c'est juste pour afficher une pauvre aide html ou un pdf, je ne trouve pas ça un progrès que d'imposer cette méthode à l'utilisateur, alors que d'autres existent et sont même a priori plus simples à implémenter...

Evidemment ce n'est pas un problème des composants en eux-même, c'est celui de leur utilisation systématique et exclusive.

Sauf que tu compares à des situations de plus en plus restrictives pour l'utilisateur en remontant dans le passé, alors que lui, non.

On a un système qui tourne très bien sans, comme dit Yeupou, et l'intérêt pour l'utilisateur n'est pas si flagrant que ça (réel, mais pas si grand, et ça dépend encore de l'utilisation qu'on en fait). Pour le programmeur, oui, pour certaines choses. De là à dire que c'est nécessaire à un environnemnt...

Ca permet aussi de ne pas réinventer la roue à chaque fois !

Bien qu'en général, ça n'en soit pas l'unique manière non plus...

Quelques fois l'interet est moindre, par exemple avec un PDF qui s'affiche directement dans le navigateur au lieu de s'ouvrir dans une fenetre séparé.

Voilà exactement le genre de truc que je trouve insupportable. Alors, que ça existe, très bien, mais j'espère que ceux qui font ça ont la présence d'esprit de placer des options permettant de lancer un viewer externe, de son choix.

Unix a toujours fonctionné sur le principe une appli par travail à effectuer, et c'est plutot efficace. Quand j'écris un mail avec mutt, ça se fait avec l'éditeur de mon choix. Ça tombe bien, un éditeur c'est fait pour éditer du texte, et ça le fait plutot bien (du moins mon éditeur favori le fait à ma convenance). Avec la plupart des clients mail graphiques, on n'a pas ce choix, il faut se contenter de l'éditeur intégré qui bien sûr est plutot pauvre, n'a pas les mêmes raccourcis claviers, etc. C'est ce que permettent les composants s'il y a un éditeur prêt à intégrer. Seulement si c'est facile à programmer, j'imagine que quand mutt demande l'exécution de l'éditeur par défaut c'est pas compliqué non plus. Et si les composants sont intéressants quand il y a vraiment interaction, assez souvent il n'y en a pas, et donc aucune raison de supprimer l'autre méthode, celle du programme externe.

Je ne parle en aucun cas de remplacer l'une par l'autre, mais de leur coexistence, quand la méthode des composants n'est pas indispensable. Je n'ai pas l'impression que les logiciels vont dans le sens de cette coexistence en ce moment, c'est bien dommage.

tu ne me feras pas croire qu'il suffit d'avoir un public pour qu'une version libre d'un soft soit créée par ses utilisateurs (a-t-on déjà vu des secrétaires programmer un traitement de texte ?)

Il n'y a justement pas que les secrétaires à avoir besoin de traitement de textes, mais des utilisateurs qui en ont besoin et qui sont capables de le faire. Que d'autres personnes, sans compétence informatique, utilisent les logiciels créés, c'est bien normal, c'est fait pour, et le logiciel libre a toujours fonctionné comme ça.

- des API d'accessibilité : capital ?

De toutes façons ça a l'air d'être présent dans GTK2 et les libs (non-Gnome) qui vont avec... donc pas une exclusivité Gnome/KDE.

enlightenment, Afterstep, GNUStep, fvwm, etc... ne sont que des gestionaires de fenêtres.

GNUStep n'est pas un gestionnaire de fenêtres, mais bien un environnement de développement.

c'est pas de Sun qu'il parlait, c'est des barbus...
-1

Non pas que je trouve que ce ne soit pas une bonne idée de prendre linux comme noyau, mais plutôt que c'est une mauvaise idée d'abandonner la conception du noyau d'atheos (de ce que j'en ai compris) qui était somme toute assez proche de celle de celui de BeOS, qui avait de multiples avantages.

J'ai pas trop compris si cet abandon était vraiment définitif ? Le système GNU a bien évolué grace à l'apport des versions GNU/Linux et aujourd'hui le Hurd avance bien plus qu'il y a quelques années. Le système GNU va bien finir par être réalisé, beaucoup de choses ayant été conçues en le faisant tourner avec le noyau Linux. Est-ce que quelque chose empêche que cette version forkée d'AtheOS retrouve un jour un noyau AtheOS, si les développeurs décident de le reprendre, après avoir mis la priorité ailleurs ?

Mais j'insiste. Pour la mise à jour d'un Woody existant, 10 heures suffisent.

Et en effet, il faut bien voir que le passage Potato->Woody aujourd'hui est plus couteux que ce dont on parle : ça fait plus d'un an et demi que ces versions sont séparées, la mise à jour correspond à un écart d'un an et demi. Mais pour des mises à jours tous les 4 mois par exemple, il y a moins de choses à ramener. En fait il faut comparer le dist-upgrade entre 2 versions de Woody séparées de 4 ou 6 mois, puisqu'on parle d'une situation dans laquelle le système est mis à jour à ce rythme.

ben, passer de la potato à une woody, ca fait plus que 162 Mo... désolé, ca c'est également testé et approuvé !

Euh faut pas oublier qu'il ne s'agit pas de ramener les 8 CDs complets, mais seulement mettre à jour ce que tu as d'installé sur ton système. Un /usr fait disons 500/700Meg, et ce qu'il y a à mettre à jour fait en général bien moins. Quand le posteur précédent dit qu'une dizaine d'heures suffit, ça me parait un ordre de grandeur réaliste. Il faut voir aussi que ce n'est à faire que tous les 5 ou 6 mois, le forfait il morfle pas tous les mois...

A combien se monte tes factures telephonique car si apt est un outil genial la connexion est par contre un fait que tu as oublie de signaler.

Comme apt peut aussi utiliser des cd-rom ce n'est pas vraiment à prendre en compte. Il n'y a pas que la solution la plus facile, celle là nécessite évidemment une connexion permanente, mais c'est comme ça pour toutes les distribs si on veut toujours avoir la version de la veille.

Une Redhat (attention ce n'est pas un Troll) est plus penible a actualiser mais au moins on peut acheter des CD contenent les actualisation pour quelques euros ..

Ce n'est certainement pas Debian qui t'empeche d'acheter des versions intermédiaires de Woody. Tu attends que Debian fournisse ce service, mais pourquoi est-ce que ce serait à eux de le faire, surtout s'ils ne sont pas commerciaux ? C'est aux vendeurs d'en profiter s'il y a une demande. Ils ne peuvent rien faire de plus, sinon corriger les "erreurs stratégiques" responsables des délais pour la prochaine fois. Quoiqu'il en soit, un minimum de lecture montre une réelle volonté des développeurs de résoudre ce problème. Problème qu'ils ne cherchent certainement pas à nier, d'après ce que j'ai lu.

Que les applications orientes utilisateurs de potato sont plutot ancienne et pas actualisee dans les revisions ce n'est pas un TROLL mais une verite certe pour certains dur a avaler mais une bien triste verite.

C'est une vérité on ne peut plus normale, c'est pas dans une révision qu'on met à jour les applications : les révisions ne servent qu'à corriger des bugs et des trous de sécurité. Pas la peine d'attendre autre chose, il n'y en aura pas, et heureusement pour la stabilité de Potato.

Que je ne veuille pas me ruiner en communication telephonique pour actualiser en permanence Woody n'est pas un Troll mais une triste realite financiere

La solution t'as été donnée, trouve quelqu'un (que tu paieras) pour te graver les isos. Es-tu allé le demander dans un LUG, as-tu cherché sur un forum Linux quelqu'un qui pourrait t'aider en ce sens ? Quoiqu'il en soit, Debian n'est pas commercial et ne peut pas aller au delà de la préparation d'ISOs. Après ce n'est plus de leur responsabilité (impossibilité de par le statut probablement).

Le fait d'exprimer son avis et ses regrets concernant cette distribution particuliere est systematiquement censuree.

Ce n'est pas ça qui ressort de tes posts, le retard de Woody tout le monde le reconnait, y compris les développeurs Debian et les candidats comme ça apparait dans les liens. Par contre tu affirmes que c'est une volonté, que la priorité de Debian ce n'est pas l'utilisateur, etc. C'est ça qui est totalement faux, et la lecture des liens référencés le démontre.

Si les développeurs Debian ne s'intéressaient pas aux utilisateurs, ils ne chercheraient pas à faire une distrib 'stable' puisqu'ils utilisent tous 'unstable' pour la plupart. Il n'y aurait que Sid, et ils en feraient la distrib officielle tous les 3 mois quelle qu'en soit la stabilité.

... qui repetent a longueur de forum que Woody est utilisable en oubliant de preciser que sans DSL et des mise-a-jour en permanence la distro ne vaut pas la peine de s'y impliquer

Il n'est pas nécessaire de tout mettre à jour, et encore moins de le faire de manière permanente. De plus des Isos de Woody sont créées régulièrement. Si ton vendeur de distribs ou ton magazine Linux n'en propose jamais, ce n'est pas de la responsabilité de Debian qui ne s'occupe pas de la vente.

Peut-etre qu'une solution "radicale" seraient de reduire le nombre tres (trop ?) importants de paquets .

Comme à chaque sortie, les paquets contenant trop de bugs et non fondamentaux sont virés, c'est ce que fait Anthony Towns en ce moment.
Concernant le nombre de paquets, ce n'est pas qu'il soit important qui pose problème, c'est plutot les développeurs inactifs (il y en a, voir les programmes) et le fait que comme il n'y a qu'un mainteneur par paquet, si celui-ci est inactif, la paquet évolue difficilement. J'avais vu une proposition simple consistant à mettre plusieurs mainteneurs sur un meme package, mais une fois encore ce ne sera envisagé que pour l'après-Woody, ils ne vont pas changer en cours de route. Des candidats proposent également des solutions pour que les développeurs inactifs et qui ont en pratique quitté le projet (mais pas officiellement) soient remplacés. En fait il y a des développeurs prets à prendre la relève, mais là les paquets sont parfois bloqués par l'organisation actuelle. Comme le dit aj dans son mail, les discussions sur les choses à améliorer ne manqueront pas après Woody.

Ceux qui auront lu les pages référencées pourront confronter ce que tu dis avec la réalité facilement. Tous les développeurs Debian souhaitent voir des distributions plus fréquentes, dans l'intérêt du projet. C'est une préoccupation importante, mais le mot d'ordre est (très logiquement) : « on finit Woody comme ça, et ensuite on améliorera le processus pour la suivante », puisque changer en cours de route ne mène à rien de bon.

Je crois que tu te méprends sur la fin de tes propos. On ne veut pas nous empêcher d'accéder à l'information (tout du moins pas dans le cas présent). Il s'agit d'en profiter pour amasser de l'argent (le mot magique) avec tout ce que ça induit (pouvoir, etc ...).

Eh bien je ne pense pas que ce soit si différent, en dehors de la motivation financière. Il ne faut pas croire que l'information serait la même et qu'il n'y a qu'une couche "accès payant" en plus. Quand des tentatives de ce style sont proposées, elles se présentent comme le seul et unique moyen de diffuser. Toute information d'origine bénévole ou ne suivant pas ce principe n'est pas prise en compte, et si elle devient illégale ça va justement dans l'intéret de ceux qui controlent. Le libre (logiciel, art) est systématiquement méprisé quand on crée des taxes sur les supports, ou quand on prépare des lois de fliquage. Ce n'est pas uniquement limiter l'accès à l'information, c'est limiter sa variété, c'est supprimer la possibilité de diffusion à ceux qui ne veulent pas suivre cet « unique système officiellement autorisé ».

avec Linux/Unix...

Aucun pourquoi ?

Linuxfr deviendrait-il un site d'annonce de sortie de film?

Je ne crois pas. Pourquoi ?

peut étre y a t'il un rapport avec linux?

Mais pourquoi veux-tu qu'il y ait un rapport avec Linux dans une news sur un film ?

si quelqu'un pouvait m'expliquer...

Il n'y a rien à expliquer, une news Cinéma dans une section Cinéma et un topic Cinéma, ça peut difficilement etre plus mal placé !

PS: -1 cas hors sujet, comme la news d'ailleurs.

La news n'est pas HS.
-1 quand meme

Je te conseille de regarder le début du Systèmes d'exploitations de Tannenbaum, il commence par ça avant les parties techniques. Enfin, c'est l'historique des OS, mais l'histoire des compilos est assez liée.

Note pour ta question qu'on peut programmer en assembleur, que parfois les compilateurs existent avant leur OS de prédilection et qu'ils sont même conçus pour l'écrire ! Autre chose je crois que quand on compile(ait?) gcc, une version minimale est d'abord créée puis il termine de se compiler... avec lui-meme !

Réflexion 1 : il faut plus de temps pour redémarrer la machine que pour compiler le noyau... Reste donc à permettre la compilation du noyau pendant le démarrage.

Non non le vrai défi c'est changer de noyau à la volée, sans rebooter !