Je suis d'accord.
Je me demande d'ailleurs toujours d'où viens la rumeur qu'il existerait des interfaces graphiques pour vim et emacs?
Je pense que gvim n'est qu'un mythe, et que les gens, tels que moi, qui considèrent que les interfaces graphiques ne sont pas forcément si efficaces que ça pour quelqu'un qui dois travailler à longueur de journée avec son clavier et n'a aucun intérêt réel à utiliser la souris si ce n'est atteindre des boutons vitaux qui n'ont pas de raccourcis clavier pratiques sont des abrutis arriérés.
Cela dis, dans mon monde d'arriéré, les systèmes d'exploitation n'ont pas besoin de 2Go de RAM, et les utilisateurs sont capables de faire leur travail avec moins de douleurs de poignet (c'est du vécu, avant de revenir aux interfaces plus centrées sur le clavier, mon bras droit me faisait souvent mal. Et je n'ai même pas 30 ans…) et plus de rapidité.
Non, non. On parle de performance et pour ça un couplage fort permet d'avoir d'améliorer les performances (plus de convention (donc moins de données échangées), chaque brique ne sait parler qu'avec une ensemble limité d'autres briques qui ne sont pas changeables).
Merci, j'avais un doute sur le propos, d'où ma question. Je suis donc d'accord sur ce point.
Ça tombe bien avec JS qui a une lib standard assez petite.
Il semblerait. Mais de nos jours, pas mal de gens considèrent ça comme un défaut (pas moi, mais bon…).
A part ça, je parlais de façon générale.
Merci pour tes éclaircissements.
Pour le C, disons qu'il faut toujours traiter le retour de fonctions comme scanf. Evidemment, comme il n'y pas de support des exceptions, soit le dev à confiance en lui et en l'utilisateur, soit il écrit un code assez lourd.
Ah, on peut aussi encapsuler, mais bon… faut aimer.
Pour le C++, en revanche, oui, ça se détecte facilement, à condition d'éviter d'utiliser l'héritage du C (et je suis un mauvais élève, j'aime toujours autant scanf/printf perso :s )
Hum… donc, Gtk est ultra moche sous linux, selon toi?
Non, parce que bon, WxWidgets, sous linux, se base sur GTK… En tout cas, je ne connais aucune application utilisant le port pour X11, vu que celui-ci n'est pas complet il me semble, et je n'ai pas non plus vue d'appli utilisant le port motif.
Sûrement parce que Debian utilise le port Gtk, cela dis. Après, si on compile WxWidgets pour utiliser Motif ou X11, on peut pas se plaindre que c'est moche, mais plutôt encenser une lib qui est capable d'utiliser plusieurs toolkits sans piper mot.
Pour rappel, l'esprit de WxWidgets, c'est d'utiliser les composants standards du système, et s'ils n'existent pas, de les implémenter.
Donc, sur windows, ils se basent sur l'api win32, et, comme beaucoup (ref needed, je sais) considèrent que gtk est l'api ""standard"" (à prendre avec beaucoup de pincettes, hein, je veux pas fâcher les utilisateurs de KDE) le port qui me semble le plus utilisé sous linux est celui basé sur Gtk.
Quant aux 5 ans d'avance de Qt… ça doit être pour ça qu'a part pour l'IDE fait exclusivement pour lui, QtCreator, que je n'apprécie d'ailleurs pas du tout, raisons esthétiques:
c'est ultra moche!
il est très pénible à intégrer?
Ah, j'imagine que KDevelop aussi dois le supporter correctement.
Ensuite, les 5 ans d'avance, j'aimerai bien voir ça, avec des preuves et une argumentation, parce que je ne considère pas que forcer un utilisateur à utiliser des fonctionnalités non standard, nécessitant une pré-compilation, pour dessiner une simple interface graphique soit être en avance.
D'ailleurs, si c'était 5 ans d'avance, j'aimerai qu'on m'explique, par exemple, pour std::vector est ré-implémenté. Par exemple.
Après… WxWidgets à des défauts, oui, c'est vrai. Mais il faut les citer. Par exemple, la version stable actuelle compile en dur les gestionnaires d'évènement, ce qui oblige à des contournements un peu dégueu pour avoir un truc dynamique. On peut aussi citer l'architecture autour des barres de menu, qui laisse quelques peu à désirer.
Mais voila, il faut au moins argumenter, et, malgré ces points, ça reste un framework important qui vois la portabilité plus dans l'esprit C++, en utilisant ce qui existe, plutôt que dans l'esprit Java, en ré-implémentant tout, comme Qt fait.
C'est redondant, je ne sais pas bien. J'ai tendance à penser que ce trio est une abstraction du système de dessin sous jacent. Et qu'à ce titre ce n'est pas vraiment une redondance, ou en tout cas, pas plus redondant que d'avoir GTK et Qt pour faire des applications desktop.
Prenons le système le plus répandu: windows.
Cas de l'application classique:
Win32 <= Qt/GtK/Wx/MFC/WhatElse <= application
Cas de l'application web:
Win32 <= Qt/GtK/Wx/MFC/WhatElse <= HTML/CSS/JS <= application
Je ne vois pas de redondance, juste une surcouche à l'utilité discutable.
Bref, j'ai découvert le pattern mvvm, j'ai adoré.
Ca, si je me plante pas, il s'agit d'un design pattern. Applicable aux applications classiques. (bien que j'aie du mal à comprendre la différence par rapport au mvc mais bon…)
Au sujet des layouts, widgets ect, comme tu le dis c'est bien développé dans ces environnements. Mais je pense cela concerne plus le bureau, que l'application.
L'application consomme ces widgets, et le bureau doit fournir un moyen à l'application de consommer le widget.
Le problème ici, c'est si les environnements de bureau ont été créés, c'est pour que l'utilisateur ne soit pas perdu à chaque fois qu'il change d'application. Avec les sites web, c'est la jungle: chaque site réinvente la roue, marche plus ou moins bien en fonction du navigateur, nécessite que l'utilisateur apprenne à utiliser l'interface, et force l'utilisateur un peu soucieux de sa sécurité à ajouter une configuration précise pour chaque site différent.
Tentons d'en rester aux spécifications, ce sont des rêves d'ingénieurs en cours d'implémentation qui ne demande qu'à être concrétisés.
Le problème, c'est que la simplicité de créer une interface avec WYSIWIG n'est plus un rêve depuis longtemps, sauf avec HTML.
HTML, c'est quand même plus primitif que Win32… Alors, c'est cool, ça veut dire qu'on peut tout réimplémenter à sa sauce… sauf qu'en fait, c'est pénible, parce qu'on à pas le choix.
On retrouve la bonne vielle idée des bons et des mauvais programmeurs
Sauf qu'il a dit qu'un mauvais ou moyen dev écrira une application plus performante en C++ qu'en JS, pas qu'un bon dev n'écrira pas une appli plus performante en JS que ce qu'il aurait pu faire en C++.
En gros, ce qu'il essaie de dire, c'est que le développeur qui n'est pas un guru créera une application plus rapide s'il code en C++ que s'il l'avait faite en JS.
Le problème, bien sûr, c'est qu'il ne la codera pas forcément aussi vite…
il y a plus de simplicité grâce à un couplage plus fort
Moins fort, plutôt, non?
Couplage plus fort, structure moins simple à faire évoluer sans tout péter… et devoir modifier en chaîne les dépendances.
Je suis d'accord que l'archi est ce qui influe le plus, après… même si le langage non, je pense que le type de langage, compilé/VM/interprété, influe également.
A noter aussi que certains langages ont une lib très riche. Le danger, pas forcément actuel de telles lib trop riches, c'est qu'elles risquent d'amener des dépendances inutiles.
Cela dis, ce problème existe avec tout type de lib, pas que les lib standards.
J'en déduis qu'il existera quelques installations où sysvinit ne sera pas utilisé par défaut.
J'imagine (imagination => pas de preuves) que ce sera exactement de la même façon qui fait que gnome n'est pas utilisé par défaut sur 2 CDs n°1 alternatifs, l'un étant dédié à KDE, l'autre à XFCE/LXDE.
Ce qui implique que les gens qui auront systemd par défaut, auront choisie l'image avec systemd par défaut. Et les images avec KDE/XFCE/LXDE par défaut ne sont pas spécialement mises en avant, et sont donc certainement les moins téléchargées.
Si on applique la même logique, excepté un nombre de "CD n°1" qui explose, il y aura effectivement un petit nombre d'installations par défaut qui auront systemd.
Rien de choquant, et je préfère de toute façon que mon OS me donne le choix.
Quand je vois ce qui se dis au sujet de systemd sur la ml debian, je doute que les développeurs n'imposent un tel changement.
De toute façon, ça ne risque pas, puisque, pour rappel, debian supporte aussi un kernel bsd, et comme tout un chacun ne cesse de le rappeler, systemd n'est pas portable.
Je pense juste qu'il y aura le choix à l'installation, quand on prend les questions en mode expert, chose qui n'est pas encore le cas à l'heure actuelle, sysvinit étant un paquet vital, contrairement à systemd.
Au hasard, il vont faire un paquet vital qui dépende sois de l'un, soit de l'autre, histoire que l'on ne sois pas obligé de taper "Oui, je suis parfaitement conscient que je risque de casser le système" quand on installe systemd et supprime sysvinit, à la virgule près? (Enfin, je dis à la virgule près, parce que le moindre caractère force à retaper, mais je n'ai pas cité le message exact :) )
Perso, je suis plutôt favorable à l'utilisation de systemd, surtout intégré par les dev de Debian qui ont tendance à faire des config par défaut très propres et très clairement documentées. Même celle de vim est lisible, à défaut d'être exhaustive dans ses commentaires.
Je me souviens avoir testé, en supprimant sysvinit, rien n'a cassé. Je suis revenu à sysvinit pour la simple raison que ça n'avais rien apporté à mes yeux à ce moment (il faut dire que les scripts d'init étaient toujours utilisés donc…), et que depuis j'ai cassé mon système, alors je n'ai pas refait la bascule.
Il y a des gens qui utilisent nano au quotidien?
Mais comment fais-tu?
Bon, après, j'avoue, je ne connais pas vi, mais vim, et il faut l'admettre: il faut apprendre à s'en servir.
D'un autre côté, je n'ai jamais vu de document prétendant qu'il n'y a pas d'apprentissage pour vim, juste affirmant qu'il est plus puissant que la plupart des autres éditeurs de texte.
Le coup des contextes différents, c'est bien ce que je voulais utiliser, même si j'ai peut-être mal formulé.
Les tableaux associatifs sont utiles, et sont la marque des bons langages dans un certain contexte. Pas dans tous.
Le C est un bon langage dans l'embarqué, je crois? Alors que perl ne le sera pas forcément. Pourtant, C n'a pas les tableaux associatifs, alors que perl, si.
Dire d'un langage qu'il est bon ou pas parce qu'il n'a pas telle ou telle fonctionnalité (qui, en l'occurrence, est une fonctionnalité implémentable, en plus) me semble franchement à côté de la plaque.
Le langage influe certainement sur la performance, mais au vu de certains codes source C que j'ai pu voir dans le libre, et la réplique que je me suis mangé quand j'ai osé suggérer d'améliorer la qualité du code et en soumettant un patch (en gros: pas de refactoring si ça n'apporte pas de fonctionnalité. Ca peut se défendre, en soi…) je ne peux qu'admettre que le développeur compte sûrement pour plus de la moitié des problèmes de performances.
Genre, si un code C fait 3 fois la même opération d'affilée à cause d'un code dégueu et illisible, même si cette opération est 2 fois plus rapide qu'en Java (exemples, exemples, rien d'autre!) si le code java ne fais qu'une fois l'opération, le code java sera plus rapide.
Ca marche aussi avec 2 et 1 ;)
Pour le desktop, ce qui pose le plus problème, à mon avis, c'est plutôt les inter-dépendances qui permettent aux logiciels de faire le café. Et le constat que je fais de ce point de vue la, c'est que le moindre programme python installé sur ma machine à bien plus de dépendances que les autres. Pour perl, c'est moins pire. Il faut dire qu'en général, ça reste des choses qui ne font qu'une seule chose, en perl.
Pour JS, j'en sais rien.
Alors bcm4313.
Perso, il faut que j'utilise le pilote propriétaire sur ma debian, sur mon 1015pem. Après, c'est sur, j'active "non-free" et "#aptitude install bcm4313" permet de régler le problème.
C'est aussi une expérience purement personnelle.
Peut-être que c'est l'âge du kernel qu'il faut mettre en cause, mais j'ai un doute. Peut-être aussi que ce sont les DFSG le problème, mais j'admets que, de façon totalement personnelle et égoïste, ces définitions collent bien à mes idées personnelles (oui j'insiste lourdement sur le mot personnel, je sais, et, au cas où: c'est totalement personnel ;) ).
Le fait est que sous windows, on trouve tous les pilotes, aucun n'étant libre, mais tous fonctionnent et s'intègrent bien avec l'OS et ses possibilités.
A côté de ça, si tout fonctionne sous linux avec des drivers propriétaires, ceux-ci ne sont pas au même niveau en terme de quantités de fonctionnalités.
J'ai cité l'économie d'énergie du pilote nouveau, qui n'est pas l'officiel (et j'aurai aussi pu citer le fait d'utiliser 2 cartes graphiques au lieu d'une seule), mais pour le privateur, l'officiel, je peux citer xrandr qui n'est pas supporté.
Côté wifi, je sais exactement comment freezer mon système. Il me suffit de changer l'état du wifi (on/off) entre une hibernation et le reboot.
Mis à part ça, ça marche, donc ok. Mais ce n'est pas un pilote libre, encore une fois.
Après, de dire que windows embarque tous les pilotes, ça m'a aussi toujours fait beaucoup rigoler. Le fait est que si "touslesdrivers.com" existe, c'est parce qu'ils en sont très loin. Et même sur ce site, on arrive très facilement à ne pas trouver, ou à trouver un truc qui ne marche pas, lorsque le matos est trop "vieux".
Mais voilà, au détour d'un reddit relayé à point nommé, John Carmack faisait une mise au point honnête sur l'intérêt de plutôt miser sur l'émulation que d'espèrer un portage de jeu natif et il saluait donc l'initiative de CodeWeavers, WineHQ.
Combien de fois faudra-t-il le répéter?
Wine n'est PAS un émulateur!!!
Il s'agit de l'implémentation d'une API, pas de la simulation du fonctionnement d'une machine.
Après, pour la diffusion physique, c'est logique, il n'y a pas grand monde qui aie une machine sous linux, alors ça serait pas mal de quantité de matériel gaspillée. Pour le retard comparé à windows, en revanche… c'est moins logique, sauf si on se dis que les logiciels (jeux ou pas) ne sont pas développés de façon portable, mais bien portés à priori.
D'ailleurs, m'est avis que ça doit coûter la peau des fesses comparé à un dev portable dès le début?
Hum… pas de merde en script, ça implique que tu n'as ni perl, ni python d'installé? Ca m'intéresse assez dans ce cas.
Bon, naturellement, je pense que tu exagères, vu que je suis persuadé (mais pas convaincu, notes bien) que tu as init, et question script… bref, sans shell (que ce soit bash, zsh ou csh ou… peu importe), je ne sais pas si un système peut tourner à l'heure actuelle.
Entièrement d'accord.
Tout le monde sait que le langage C et le langage ASM ne sont pas de vrais langages, l'un n'ayant pas de tableau associatif dans sa lib standard, l'autre n'ayant même pas de lib standard!
Quelle honte!
Bon, d'un autre côté, mieux vaut lire ça que d'être aveugle… C'est pas comme si je suis fan de l'asm ou du C (je ne dirais pas tout le mal bien que je pense de JS non plus), mais les tableaux associatifs ne sont pas aussi vitaux que tu ne sembles le croire, de très, très nombreuses applications s'en passent avec bonheur.
D'ailleurs, tant qu'a troller, un tableau normal, n'est-ce pas un tableau associatif, puisque l'on associe un index avec une donnée?
Une branche stable qui ne fait que des fix de sécurité, 0 modifs de "l'API de configuration" (une conf, c'est un peu comme une API si on y pense, non?), et une branche "dev" qui comprend les ajouts/suppressions/modif de features, avec des changelog qui expliquent que telle ou telle option à vu son comportement modifié.
Pour le coup, séparer les données du code à un intérêt: on peu faire autant de MaJ de sécu qu'on veux, ça ne touche pas à la config.
Pour être honnête, cette manie de mêler le code et des constantes, c'est quelque chose qui m'a valu de nombreuses heure de débogage, et maintenant, quand j'ai une donnée initialisée par une constante qui n'a rien a voir avec le fonctionnement interne de mon appli (genre, par 0 ou 1 en fonction des index de tableau, ou un code/message d'erreur que je mets dans le texte décrivant l'erreur), ça dégage dans un fichier de conf (que la configuration aie lieu à la compilation où à l'exécution ne change pas que ça reste de la configuration) , séparé de la logique du code.
L'autre point sympa, outre la maintenance, c'est que ça génère de facto un logiciel plus souple, avec moins de limites codées en dur et pénibles à faire évoluer (je trouve que "%s/…/…/g" c'est long à taper, et encore pire quand ça contiens des /, . ou autres joyeusetés)
Je souhaiterais au passage rappeler qu'un dossier et une base de données, c'est assez proche, modulo la méthode pour trouver la donnée (par clé/hash/node…).
Le registre windows, c'est: une structure en arbre, contenant des couples clé/valeur.
Un système de fichier, c'est: une structure en arbre (les dossiers étant les noeuds) contenant des couples clé/valeur (les fichiers sont la valeur, leur nom est la clé).
Dans les deux cas, on peut stoker une valeur texte, ou binaire. Niveau base de registre windows, ce que je n'aime pas, c'est:
1) Pas éditable par éditeur de texte simple (et, non, vim n'est pas simple, même s'il à des points qui font que je l'utilise de plus en plus.)
2) Je ne comprend pas l'intérêt d'ajouter une complexité pour une configuration qui n'est censée n'être lue qu'une fois: au début du lancement d'un logiciel.
3) Le foutoir (selon moi, et c'est de toute façon entièrement lié à ce registre précis)
Ce que j'aime avec mon /etc, c'est:
1) Les commandes du bash sont disponibles, sans adaptation. Ca implique que les scripts ne nécessitent pas d'apprendre un nouveau langage. D'ailleurs, la plupart des langages savent se démerder avec des fichiers et dossiers.
2) Je peux utiliser n'importe quel logiciel de versionning. Git, svn, cp.old…
C'est un peu comme le xml (tant qu'a troller, trollons bien) que tout le monde pense être la panacée: dans énormément de cas, il n'a aucune intérêt si ce n'est d'être à la mode.
Euh… Non. Je gagne mon fric en développement de nouvelles fonctionnalités.
Hum, aussi effectivement, j'avais oublié ce point.
et les informaticiens n'ont pas nécessairement besoin de support, surtout aux débuts du logiciel ou si sa documentation, signe de qualité, est propre et complète
Oui, c'est l'avantage même : tu te fait pas chier à faire des trucs simples.
Par contre, ben si : tout le monde n'a pas envie de faire les trucs compliqués en apprenant trop, et préfèrent déléguer, et qui de mieux que le dév pour?
Le fait est que, si on se fait pas chier pour un truc simple, il y a moins besoin d'assistance, et donc moins de rentrée d'argent potentielle. Je parle d'un point de vue purement économique la, hein.
Mais je pense que le risque d'avoir bossé pour rien et de se ramasser la gueule,
Comme partout.
tu as oublié la fin: "est plus élevé". Il est évident qu'on peut se ramasser partout… je pense juste que le début, avec le libre, me semble bien plus délicat qu'avec un modèle fermé.
voire de se faire piquer son idée par une entreprise peu scrupuleuse,
Ben c'est que quelqu'un est meilleur que toi, à toi de changer!
Un logiciel qui viens de naître, fait par un type seul, n'a aucune chance de pouvoir concurrencer au niveau des compétences une entreprise sur le même marché depuis belle lurette, ne serait-ce qu'en terme de force de travail.
Tu peux être aussi excellent que tu veux, si en face tu as une équipe d'une 10aine de dev ayant entre 5 et 10 d'expérience dans le même domaine, je doute que ce soit possible.
Yakafokon s'améliore, c'est pas toujours si simple que ça, quoi.
Parce qu'on ne me fera pas croire que toutes les entreprises jouent le jeu quand elles emploient un logiciel libre…
Quel jeu? C'est libre, elles font ce qu'elles veulent, il n'y a aucune règle "tu dois contribuer upstream", ce serait même contre le libre.
Ce que tu vends en tant que dev principal, c'est ta compétence. Et si toi le dev principal tu es moins compétent que d'autres, ça craint! Aucune autre personne ne peut être meilleure et "ne pas jouer le jeu"…
Tant pis pour les deb, ça m'aurait bien intéressé. Enfin, je sais en faire, mais ma méthode est un peu trop artisanale à mon goût, et la méthode recommandée de debian, j'ai pas tout compris :D
Pour ce qui est de la réécriture, je comprend vraiment ce que tu veux dire. Je pense que réécrire complètement un logiciel dans le même langage est une erreur, dans l'absolu: ça casse la motivation de repartir sur un truc qui ne marche pas, on perds l'historique des bugs, et on se prend la tête à utiliser des choses pas forcément utiles.
Changer de langage… c'est pas pareil, il n'y a pas forcément le choix de tout refaire d'un bloc (genre delphi à C++) sauf peut-être si l'on connaît l'ancien code.
C'est con à dire, mais… le matos, ça coûte. J'ai toujours eu envie de me faire ce genre d'amis, plus fidèle qu'un chien, moins cher, et plus propre.
Seulement, le prix supposé m'a toujours fait peur!
[^] # Re: Mauvaise interprétation
Posté par freem . En réponse au journal Systemd dans Debian. Évalué à 2.
Je suis d'accord.
Je me demande d'ailleurs toujours d'où viens la rumeur qu'il existerait des interfaces graphiques pour vim et emacs?
Je pense que gvim n'est qu'un mythe, et que les gens, tels que moi, qui considèrent que les interfaces graphiques ne sont pas forcément si efficaces que ça pour quelqu'un qui dois travailler à longueur de journée avec son clavier et n'a aucun intérêt réel à utiliser la souris si ce n'est atteindre des boutons vitaux qui n'ont pas de raccourcis clavier pratiques sont des abrutis arriérés.
Cela dis, dans mon monde d'arriéré, les systèmes d'exploitation n'ont pas besoin de 2Go de RAM, et les utilisateurs sont capables de faire leur travail avec moins de douleurs de poignet (c'est du vécu, avant de revenir aux interfaces plus centrées sur le clavier, mon bras droit me faisait souvent mal. Et je n'ai même pas 30 ans…) et plus de rapidité.
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 0.
Merci, j'avais un doute sur le propos, d'où ma question. Je suis donc d'accord sur ce point.
Il semblerait. Mais de nos jours, pas mal de gens considèrent ça comme un défaut (pas moi, mais bon…).
A part ça, je parlais de façon générale.
Merci pour tes éclaircissements.
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 0.
Pour le C, disons qu'il faut toujours traiter le retour de fonctions comme scanf. Evidemment, comme il n'y pas de support des exceptions, soit le dev à confiance en lui et en l'utilisateur, soit il écrit un code assez lourd.
Ah, on peut aussi encapsuler, mais bon… faut aimer.
Pour le C++, en revanche, oui, ça se détecte facilement, à condition d'éviter d'utiliser l'héritage du C (et je suis un mauvais élève, j'aime toujours autant scanf/printf perso :s )
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 1.
http://en.wikipedia.org/wiki/List_of_widget_toolkits#Cross-platform
Histoire de.
J'ai pas compté, mais à vue de nez, je dirais, une 20aine?
Il ne faut pas confondre "candidats pas nombreux" et "nombreux candidats peu connus" ;)
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 0.
Mais plus lent si on ne les utilise pas.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à -1.
Hum… donc, Gtk est ultra moche sous linux, selon toi?
Non, parce que bon, WxWidgets, sous linux, se base sur GTK… En tout cas, je ne connais aucune application utilisant le port pour X11, vu que celui-ci n'est pas complet il me semble, et je n'ai pas non plus vue d'appli utilisant le port motif.
Sûrement parce que Debian utilise le port Gtk, cela dis. Après, si on compile WxWidgets pour utiliser Motif ou X11, on peut pas se plaindre que c'est moche, mais plutôt encenser une lib qui est capable d'utiliser plusieurs toolkits sans piper mot.
Pour rappel, l'esprit de WxWidgets, c'est d'utiliser les composants standards du système, et s'ils n'existent pas, de les implémenter.
Donc, sur windows, ils se basent sur l'api win32, et, comme beaucoup (ref needed, je sais) considèrent que gtk est l'api ""standard"" (à prendre avec beaucoup de pincettes, hein, je veux pas fâcher les utilisateurs de KDE) le port qui me semble le plus utilisé sous linux est celui basé sur Gtk.
Quant aux 5 ans d'avance de Qt… ça doit être pour ça qu'a part pour l'IDE fait exclusivement pour lui, QtCreator, que je n'apprécie d'ailleurs pas du tout, raisons esthétiques:
il est très pénible à intégrer?
Ah, j'imagine que KDevelop aussi dois le supporter correctement.
Ensuite, les 5 ans d'avance, j'aimerai bien voir ça, avec des preuves et une argumentation, parce que je ne considère pas que forcer un utilisateur à utiliser des fonctionnalités non standard, nécessitant une pré-compilation, pour dessiner une simple interface graphique soit être en avance.
D'ailleurs, si c'était 5 ans d'avance, j'aimerai qu'on m'explique, par exemple, pour std::vector est ré-implémenté. Par exemple.
Après… WxWidgets à des défauts, oui, c'est vrai. Mais il faut les citer. Par exemple, la version stable actuelle compile en dur les gestionnaires d'évènement, ce qui oblige à des contournements un peu dégueu pour avoir un truc dynamique. On peut aussi citer l'architecture autour des barres de menu, qui laisse quelques peu à désirer.
Mais voila, il faut au moins argumenter, et, malgré ces points, ça reste un framework important qui vois la portabilité plus dans l'esprit C++, en utilisant ce qui existe, plutôt que dans l'esprit Java, en ré-implémentant tout, comme Qt fait.
[^] # Re: En fait c'est la page qui est mal faite...
Posté par freem . En réponse au journal GoPro OpenSource. Évalué à 1.
Ca, c'est la version chiffrée avec xor (clé binaire: 10011001)
[^] # Re: javascript, ok.
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 4.
Prenons le système le plus répandu: windows.
Cas de l'application classique:
Win32 <= Qt/GtK/Wx/MFC/WhatElse <= application
Cas de l'application web:
Win32 <= Qt/GtK/Wx/MFC/WhatElse <= HTML/CSS/JS <= application
Je ne vois pas de redondance, juste une surcouche à l'utilité discutable.
Ca, si je me plante pas, il s'agit d'un design pattern. Applicable aux applications classiques. (bien que j'aie du mal à comprendre la différence par rapport au mvc mais bon…)
Le problème ici, c'est si les environnements de bureau ont été créés, c'est pour que l'utilisateur ne soit pas perdu à chaque fois qu'il change d'application. Avec les sites web, c'est la jungle: chaque site réinvente la roue, marche plus ou moins bien en fonction du navigateur, nécessite que l'utilisateur apprenne à utiliser l'interface, et force l'utilisateur un peu soucieux de sa sécurité à ajouter une configuration précise pour chaque site différent.
Le problème, c'est que la simplicité de créer une interface avec WYSIWIG n'est plus un rêve depuis longtemps, sauf avec HTML.
HTML, c'est quand même plus primitif que Win32… Alors, c'est cool, ça veut dire qu'on peut tout réimplémenter à sa sauce… sauf qu'en fait, c'est pénible, parce qu'on à pas le choix.
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
Sauf qu'il a dit qu'un mauvais ou moyen dev écrira une application plus performante en C++ qu'en JS, pas qu'un bon dev n'écrira pas une appli plus performante en JS que ce qu'il aurait pu faire en C++.
En gros, ce qu'il essaie de dire, c'est que le développeur qui n'est pas un guru créera une application plus rapide s'il code en C++ que s'il l'avait faite en JS.
Le problème, bien sûr, c'est qu'il ne la codera pas forcément aussi vite…
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 0.
Moins fort, plutôt, non?
Couplage plus fort, structure moins simple à faire évoluer sans tout péter… et devoir modifier en chaîne les dépendances.
Je suis d'accord que l'archi est ce qui influe le plus, après… même si le langage non, je pense que le type de langage, compilé/VM/interprété, influe également.
A noter aussi que certains langages ont une lib très riche. Le danger, pas forcément actuel de telles lib trop riches, c'est qu'elles risquent d'amener des dépendances inutiles.
Cela dis, ce problème existe avec tout type de lib, pas que les lib standards.
[^] # Re: Ah l'anglais...
Posté par freem . En réponse au journal Systemd dans Debian. Évalué à 1.
J'imagine (imagination => pas de preuves) que ce sera exactement de la même façon qui fait que gnome n'est pas utilisé par défaut sur 2 CDs n°1 alternatifs, l'un étant dédié à KDE, l'autre à XFCE/LXDE.
Ce qui implique que les gens qui auront systemd par défaut, auront choisie l'image avec systemd par défaut. Et les images avec KDE/XFCE/LXDE par défaut ne sont pas spécialement mises en avant, et sont donc certainement les moins téléchargées.
Si on applique la même logique, excepté un nombre de "CD n°1" qui explose, il y aura effectivement un petit nombre d'installations par défaut qui auront systemd.
Rien de choquant, et je préfère de toute façon que mon OS me donne le choix.
[^] # Re: Je ne comprends pas ces sous-entendus
Posté par freem . En réponse au journal Systemd dans Debian. Évalué à 2.
Quand je vois ce qui se dis au sujet de systemd sur la ml debian, je doute que les développeurs n'imposent un tel changement.
De toute façon, ça ne risque pas, puisque, pour rappel, debian supporte aussi un kernel bsd, et comme tout un chacun ne cesse de le rappeler, systemd n'est pas portable.
Je pense juste qu'il y aura le choix à l'installation, quand on prend les questions en mode expert, chose qui n'est pas encore le cas à l'heure actuelle, sysvinit étant un paquet vital, contrairement à systemd.
Au hasard, il vont faire un paquet vital qui dépende sois de l'un, soit de l'autre, histoire que l'on ne sois pas obligé de taper "Oui, je suis parfaitement conscient que je risque de casser le système" quand on installe systemd et supprime sysvinit, à la virgule près? (Enfin, je dis à la virgule près, parce que le moindre caractère force à retaper, mais je n'ai pas cité le message exact :) )
Perso, je suis plutôt favorable à l'utilisation de systemd, surtout intégré par les dev de Debian qui ont tendance à faire des config par défaut très propres et très clairement documentées. Même celle de vim est lisible, à défaut d'être exhaustive dans ses commentaires.
Je me souviens avoir testé, en supprimant sysvinit, rien n'a cassé. Je suis revenu à sysvinit pour la simple raison que ça n'avais rien apporté à mes yeux à ce moment (il faut dire que les scripts d'init étaient toujours utilisés donc…), et que depuis j'ai cassé mon système, alors je n'ai pas refait la bascule.
[^] # Re: Mauvaise interprétation
Posté par freem . En réponse au journal Systemd dans Debian. Évalué à -1.
Il y a des gens qui utilisent nano au quotidien?
Mais comment fais-tu?
Bon, après, j'avoue, je ne connais pas vi, mais vim, et il faut l'admettre: il faut apprendre à s'en servir.
D'un autre côté, je n'ai jamais vu de document prétendant qu'il n'y a pas d'apprentissage pour vim, juste affirmant qu'il est plus puissant que la plupart des autres éditeurs de texte.
Pour cron user-friendly… j'ai bien rigolé, merci.
[^] # Re: Choix discutable
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 3.
Le coup des contextes différents, c'est bien ce que je voulais utiliser, même si j'ai peut-être mal formulé.
Les tableaux associatifs sont utiles, et sont la marque des bons langages dans un certain contexte. Pas dans tous.
Le C est un bon langage dans l'embarqué, je crois? Alors que perl ne le sera pas forcément. Pourtant, C n'a pas les tableaux associatifs, alors que perl, si.
Dire d'un langage qu'il est bon ou pas parce qu'il n'a pas telle ou telle fonctionnalité (qui, en l'occurrence, est une fonctionnalité implémentable, en plus) me semble franchement à côté de la plaque.
En espérant que mon message soie plus clair.
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 1. Dernière modification le 07 février 2013 à 14:02.
Le langage influe certainement sur la performance, mais au vu de certains codes source C que j'ai pu voir dans le libre, et la réplique que je me suis mangé quand j'ai osé suggérer d'améliorer la qualité du code et en soumettant un patch (en gros: pas de refactoring si ça n'apporte pas de fonctionnalité. Ca peut se défendre, en soi…) je ne peux qu'admettre que le développeur compte sûrement pour plus de la moitié des problèmes de performances.
Genre, si un code C fait 3 fois la même opération d'affilée à cause d'un code dégueu et illisible, même si cette opération est 2 fois plus rapide qu'en Java (exemples, exemples, rien d'autre!) si le code java ne fais qu'une fois l'opération, le code java sera plus rapide.
Ca marche aussi avec 2 et 1 ;)
Pour le desktop, ce qui pose le plus problème, à mon avis, c'est plutôt les inter-dépendances qui permettent aux logiciels de faire le café. Et le constat que je fais de ce point de vue la, c'est que le moindre programme python installé sur ma machine à bien plus de dépendances que les autres. Pour perl, c'est moins pire. Il faut dire qu'en général, ça reste des choses qui ne font qu'une seule chose, en perl.
Pour JS, j'en sais rien.
[^] # Re: bof
Posté par freem . En réponse au journal Interview de Greg Kroah-Hartman. Évalué à 0.
Alors bcm4313.
Perso, il faut que j'utilise le pilote propriétaire sur ma debian, sur mon 1015pem. Après, c'est sur, j'active "non-free" et "#aptitude install bcm4313" permet de régler le problème.
C'est aussi une expérience purement personnelle.
Peut-être que c'est l'âge du kernel qu'il faut mettre en cause, mais j'ai un doute. Peut-être aussi que ce sont les DFSG le problème, mais j'admets que, de façon totalement personnelle et égoïste, ces définitions collent bien à mes idées personnelles (oui j'insiste lourdement sur le mot personnel, je sais, et, au cas où: c'est totalement personnel ;) ).
Le fait est que sous windows, on trouve tous les pilotes, aucun n'étant libre, mais tous fonctionnent et s'intègrent bien avec l'OS et ses possibilités.
A côté de ça, si tout fonctionne sous linux avec des drivers propriétaires, ceux-ci ne sont pas au même niveau en terme de quantités de fonctionnalités.
J'ai cité l'économie d'énergie du pilote nouveau, qui n'est pas l'officiel (et j'aurai aussi pu citer le fait d'utiliser 2 cartes graphiques au lieu d'une seule), mais pour le privateur, l'officiel, je peux citer xrandr qui n'est pas supporté.
Côté wifi, je sais exactement comment freezer mon système. Il me suffit de changer l'état du wifi (on/off) entre une hibernation et le reboot.
Mis à part ça, ça marche, donc ok. Mais ce n'est pas un pilote libre, encore une fois.
Après, de dire que windows embarque tous les pilotes, ça m'a aussi toujours fait beaucoup rigoler. Le fait est que si "touslesdrivers.com" existe, c'est parce qu'ils en sont très loin. Et même sur ce site, on arrive très facilement à ne pas trouver, ou à trouver un truc qui ne marche pas, lorsque le matos est trop "vieux".
[^] # Re: Quel est le but du portage ?
Posté par freem . En réponse à la dépêche Portage de Wine en cours sur Android. Évalué à 1.
Combien de fois faudra-t-il le répéter?
Wine n'est PAS un émulateur!!!
Il s'agit de l'implémentation d'une API, pas de la simulation du fonctionnement d'une machine.
Après, pour la diffusion physique, c'est logique, il n'y a pas grand monde qui aie une machine sous linux, alors ça serait pas mal de quantité de matériel gaspillée. Pour le retard comparé à windows, en revanche… c'est moins logique, sauf si on se dis que les logiciels (jeux ou pas) ne sont pas développés de façon portable, mais bien portés à priori.
D'ailleurs, m'est avis que ça doit coûter la peau des fesses comparé à un dev portable dès le début?
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
Hum… pas de merde en script, ça implique que tu n'as ni perl, ni python d'installé? Ca m'intéresse assez dans ce cas.
Bon, naturellement, je pense que tu exagères, vu que je suis persuadé (mais pas convaincu, notes bien) que tu as init, et question script… bref, sans shell (que ce soit bash, zsh ou csh ou… peu importe), je ne sais pas si un système peut tourner à l'heure actuelle.
[^] # Re: Choix discutable
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 3.
Entièrement d'accord.
Tout le monde sait que le langage C et le langage ASM ne sont pas de vrais langages, l'un n'ayant pas de tableau associatif dans sa lib standard, l'autre n'ayant même pas de lib standard!
Quelle honte!
Bon, d'un autre côté, mieux vaut lire ça que d'être aveugle… C'est pas comme si je suis fan de l'asm ou du C (je ne dirais pas tout le
malbien que je pense de JS non plus), mais les tableaux associatifs ne sont pas aussi vitaux que tu ne sembles le croire, de très, très nombreuses applications s'en passent avec bonheur.D'ailleurs, tant qu'a troller, un tableau normal, n'est-ce pas un tableau associatif, puisque l'on associe un index avec une donnée?
[^] # Re: Et pour en remettre une couche
Posté par freem . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Si, il y en a une:
Une branche stable qui ne fait que des fix de sécurité, 0 modifs de "l'API de configuration" (une conf, c'est un peu comme une API si on y pense, non?), et une branche "dev" qui comprend les ajouts/suppressions/modif de features, avec des changelog qui expliquent que telle ou telle option à vu son comportement modifié.
Pour le coup, séparer les données du code à un intérêt: on peu faire autant de MaJ de sécu qu'on veux, ça ne touche pas à la config.
Pour être honnête, cette manie de mêler le code et des constantes, c'est quelque chose qui m'a valu de nombreuses heure de débogage, et maintenant, quand j'ai une donnée initialisée par une constante qui n'a rien a voir avec le fonctionnement interne de mon appli (genre, par 0 ou 1 en fonction des index de tableau, ou un code/message d'erreur que je mets dans le texte décrivant l'erreur), ça dégage dans un fichier de conf (que la configuration aie lieu à la compilation où à l'exécution ne change pas que ça reste de la configuration) , séparé de la logique du code.
L'autre point sympa, outre la maintenance, c'est que ça génère de facto un logiciel plus souple, avec moins de limites codées en dur et pénibles à faire évoluer (je trouve que "%s/…/…/g" c'est long à taper, et encore pire quand ça contiens des /, . ou autres joyeusetés)
[^] # Re: Et pour en remettre une couche
Posté par freem . En réponse au journal Systemd: tuons les mythes. Évalué à 1.
Je souhaiterais au passage rappeler qu'un dossier et une base de données, c'est assez proche, modulo la méthode pour trouver la donnée (par clé/hash/node…).
Le registre windows, c'est: une structure en arbre, contenant des couples clé/valeur.
Un système de fichier, c'est: une structure en arbre (les dossiers étant les noeuds) contenant des couples clé/valeur (les fichiers sont la valeur, leur nom est la clé).
Dans les deux cas, on peut stoker une valeur texte, ou binaire. Niveau base de registre windows, ce que je n'aime pas, c'est:
1) Pas éditable par éditeur de texte simple (et, non, vim n'est pas simple, même s'il à des points qui font que je l'utilise de plus en plus.)
2) Je ne comprend pas l'intérêt d'ajouter une complexité pour une configuration qui n'est censée n'être lue qu'une fois: au début du lancement d'un logiciel.
3) Le foutoir (selon moi, et c'est de toute façon entièrement lié à ce registre précis)
Ce que j'aime avec mon /etc, c'est:
1) Les commandes du bash sont disponibles, sans adaptation. Ca implique que les scripts ne nécessitent pas d'apprendre un nouveau langage. D'ailleurs, la plupart des langages savent se démerder avec des fichiers et dossiers.
2) Je peux utiliser n'importe quel logiciel de versionning. Git, svn, cp.old…
C'est un peu comme le xml (tant qu'a troller, trollons bien) que tout le monde pense être la panacée: dans énormément de cas, il n'a aucune intérêt si ce n'est d'être à la mode.
[^] # Re: Tu connais l'histoire de Paf le prolétaire?
Posté par freem . En réponse au journal Mission d’expertise sur la fiscalité de l’économie numérique . Évalué à 1.
Ca, c'est ridicule… Un salarié ne fournit pas un travail gratuit, sinon c'est un bénévole.
Après, dire que les salariés sont exploités, c'est un autre sujet… et un autre mot.
[^] # Re: Libre, viable, oui, sûrement, mais...
Posté par freem . En réponse au journal Une preuve de plus que le libre est viable. Évalué à 1.
Hum, aussi effectivement, j'avais oublié ce point.
Le fait est que, si on se fait pas chier pour un truc simple, il y a moins besoin d'assistance, et donc moins de rentrée d'argent potentielle. Je parle d'un point de vue purement économique la, hein.
tu as oublié la fin: "est plus élevé". Il est évident qu'on peut se ramasser partout… je pense juste que le début, avec le libre, me semble bien plus délicat qu'avec un modèle fermé.
Un logiciel qui viens de naître, fait par un type seul, n'a aucune chance de pouvoir concurrencer au niveau des compétences une entreprise sur le même marché depuis belle lurette, ne serait-ce qu'en terme de force de travail.
Tu peux être aussi excellent que tu veux, si en face tu as une équipe d'une 10aine de dev ayant entre 5 et 10 d'expérience dans le même domaine, je doute que ce soit possible.
Yakafokon s'améliore, c'est pas toujours si simple que ça, quoi.
Parce qu'on ne me fera pas croire que toutes les entreprises jouent le jeu quand elles emploient un logiciel libre…
Pas tant que ça… cf ma réponse précédente.
Certes.
[^] # Re: Cru à une révolution du genre...
Posté par freem . En réponse à la dépêche Slime Volley 2.6 en vue : appel à contributions. Évalué à 1.
Tant pis pour les deb, ça m'aurait bien intéressé. Enfin, je sais en faire, mais ma méthode est un peu trop artisanale à mon goût, et la méthode recommandée de debian, j'ai pas tout compris :D
Pour ce qui est de la réécriture, je comprend vraiment ce que tu veux dire. Je pense que réécrire complètement un logiciel dans le même langage est une erreur, dans l'absolu: ça casse la motivation de repartir sur un truc qui ne marche pas, on perds l'historique des bugs, et on se prend la tête à utiliser des choses pas forcément utiles.
Changer de langage… c'est pas pareil, il n'y a pas forcément le choix de tout refaire d'un bloc (genre delphi à C++) sauf peut-être si l'on connaît l'ancien code.
# Et le prix?
Posté par freem . En réponse au journal Je me fais des amis (au sens littéral). Évalué à 2.
C'est con à dire, mais… le matos, ça coûte. J'ai toujours eu envie de me faire ce genre d'amis, plus fidèle qu'un chien, moins cher, et plus propre.
Seulement, le prix supposé m'a toujours fait peur!
Pourrais t-on avoir une estimation?