Vendredi ou pas, je m'en moque. De toute façon, je passe aléatoirement donc bon…
Cependant, j'ai lu à plusieurs reprise ce point précis: deb à été créé plusieurs années avant rpm, mais rpm à été """sacré""" format universel des package linux.
Mais je n'ai jamais vu la moindre raison technique ( oui, je sais, on est lundi, pas trolldi… ) expliquant cette raison.
Donc, ma question est simple: y a t-il une seule raison objective ayant permis d'élire rpm comme format universel?
Sachant que, bien sûr, deb à ses défauts, par exemple il est impossible d'installer un deb en userspace avec les outils standard. Mais si rpm à le même problème, alors… bref.
Une raison technique derrière ce choix, ou c'est encore une question de blé?
Mon opinion sur le sujet est très simple.
Les auteurs d'un logiciels sont en droit de refuser aux autres le droit de le modifier. Ca ne me pose pas plus de souci que ça.
Pourquoi ça ne me pose pas plus de souci que ça?
C'est simple: si quelqu'un n'est pas d'accord, il n'a qu'a faire mieux. Tant qu'il n'y a pas de copyright stupide empêchant la compétition, et tant que les standards sont suivis alors qu'ils n'empêchent pas le progrès, il n'y a pas de mal.
Le point étant que, même si j'aime l'idée du libre et même si je lui reconnaît nombre de qualité, je lui admets surtout la qualité de choisir d'être libéré ou pas. La liberté implique la prise de risque, et tout le monde n'est pas prêt à acheter sa liberté dans ces conditions. Conditions que, personnellement, j'accepte avec des compromis, puisque j'utilise moi-même des logiciels non libres ( flash, opera et le pilote nvidia. Oui, l'un d'entre eux à une alternative """libre""" populaire et 100% fonctionnelle, et de nombreuses alternatives libres tout court. Mais justement, je l'ai choisi en toute liberté de choix et en comprenant le contrat que j'ai signé numériquement, donc je suis libre. Je suis également libre de me passer de vidéos sur le net et d'utiliser pleinement le GPU de ma tour… je l'ai déjà fait.)
Permets moi de rebondir sur ta réponse, et de demander ce qu'apporte et enlève exactement openRC à 1) sysVinit et 2) systemd.
Du peu que je suppose avoir compris du peu que j'ai lu ( ça fait beaucoup de peu, mais j'ai encore peur de surestimer l'état de mes connaissances… imagines le travail :) ) :
_ openRC conserve la complexité d'écriture de scripts de sysVinit ( j'entends par la que la syntaxe utilisée est celle de sh, ce qui est complexe du point de vue utilisateur, pas de celui du système )
_ mais openRC permets de paralléliser les tâches ( comme pour systemd ) . Chose qui d'ailleurs m'intrigue vu que j'ai lu diverses allégations laissant supposer que sysVinit en serait aussi capable ( on parle de script shell dans les 2 cas si je ne m'abuse, donc ça ne m'a pas semblé irréaliste )
_ tout en n' ( emphase sur la négation ) ayant pas les tonnes de dépendances de systemd à des modules non vitaux pour un OS minimal ( c'est à dire, pas de dépendance à dbus ou logind, par exemple ).
Mouai.
J'aurai plutôt dit qu'il n'y a pas de NIH ici, systemd tout comme upstart apportent des fonctionnalités et une architecture que n'a pas sysVinit.
Le NIH, c'est juste réimplémenter un outil ayant les mêmes fonctionnalités qu'une alternative non-contraignante ( par rapport au nouveau projet, et, oui, cela inclue les problème de licence. ) déjà existante propose.
D'un autre côté, ne pas mettre de CLA, c'est une ""erreur"" ( double guillemets, vous avez vu? ) que divers projets ont faits, projets qui ont ensuite dû contacter les contributeurs 1 par 1 pour essayer d'unifier les licences.
Dans un univers ( impitoyable genre dallas ) tel que l'open source, ce genre de choses ( ne pas imposer de CLA ) peut tuer un projet sur le long terme, tandis qu'avec un CLA, les choses sont claires dès le début, contribue qui veut, forke qui veut, ce qui assure que l'équipe du projet sera toujours apte à faire avancer le projet dans la direction qu'elle souhaite.
Après… c'est sûr, un CLA sans conditions, c'est dangereux pour la liberté du projet, mais on sort clairement du problème généraliste du CLA pour entrer dans la spécialisation du CLA potentiellement privatif.
PS: j'ai hésité sur le terme privatif, mais à force je ne sais plus lequel entre privateur et privatif est réellement français…
Je vais sûrement t'accompagner dans le karma négatif, mais j'admets que ça ne me dérange pas.
Je voulais juste te remercier d'être aussi insistant dans l'art de foutre des coups de pieds dans les fourmilières et de casser les consensus. Le bouton "pertinent" ne le permettant pas quand on arrive à un stade de moinssage aussi important, je me permets ce commentaire inutile.
Désolé, mais le nombre de pulse machin sur mon système est inférieur à celui des modules systemd. Ou du moins, plus simple à rendre tel:
$ aptitude search ~i |grep pulse
i A libpulse-dev - PulseAudio client development headers and
i A libpulse-mainloop-glib0 - bibliothèques clients PulseAudio - gestion
i A libpulse0 - bibliothèques clientes PulseAudio
A noter que les raisons d'installation de ces paquets sont, pour les 2 1ers, la lib de dev de SDL, et pour le 3eme, mplayer.
Systemd, en revanche, c'est plus chiant:
mpd en dépend ( libsystemd-daemon0 )
dbus en dépend ( libsystemd-journal0 ainsi que libsystemd-login0 et pour virer dbus, sans perdre de fonctionnalités, bon courage! )
Bref, rien de comparable. Le 1er ( PA ) ne squatte quasiment que via certaines lib de dev, tandis que l'autre s'incruste au travers d'outils centraux du système.
Je suis à la fois d'accord et pas d'accord au sujet du vectoriel.
Le vectoriel me semble plus adapté, clairement, parce que plus léger sur le réseau. Enfin, plus léger… si et seulement si on essaie pas de transmettre des photos! Pour des graphismes simples, du genre de ceux du thème qu'on avait du temps de windows 98.
Si on se concentrait sur des thèmes fonctionnels plutôt qu'esthétiques, alors le vectoriel serait le plus adapté ( et par forcément le SVG, qui est hyper verbeux à cause de son héritage XML. Je ne sais pas si d'autres format vectoriel plus efficaces existent? ), léger sur le réseau pour une surcharge CPU/GPU raisonnable.
En fait, c'est comme pour tout: il y a plusieurs solutions, chacune étant plus efficace en fonction de la situation. RDP doit probablement faire de la compression et sélection de zone ( à vous lire ), et donc plus efficace pour un environnement utilisant des graphismes de plus haute qualité, alors que le vectoriel serait plus efficace pour un thème épuré.
La conséquence est qu'avec wayland, il faudra obligatoirement utiliser un logiciel tiers pour de l'affichage distant.
D'un autre côté, ce n'était pas le but de wayland de base, qui me semble plus cibler l'ordinateur personnel ( j'inclue dans ce terme les trucphones et les ordinateurs de voiture par exemple ) au lieu des serveurs d'applications.
X me semble plus conçu pour les serveurs d'applications, c'est à dire pour les contraintes de coût d'il y a 30 ans, ou les ordinateurs étaient tellement coûteux qu'il était plus économique d'avoir un serveur d'application auquel se connectent des terminaux ( du genre incapables de faire quoique ce soit sans réseau. Nos machines actuelles, même si elles sont souvent uniquement utilisées avec un stupide navigateur internet, restent capables de faire des choses sans internet. C'est juste leurs utilisateurs qui n'en sont plus trop capables. ).
A l'heure actuelle, n'importe quel gadget est assez puissant pour faire tourner les applications par lui-même, donc les serveurs d'applications n'ont plus un très grand intérêt, et c'est probablement pour ça que l'équipe de wayland n'a pas voulu s'embêter avec cette fonctionnalité. Enfin, c'est ce que je suppose.
Et puis, VNC existe et est plus efficace ( il paraît, je n'ai jamais testé personnellement ) qu'utiliser Xorg directement.
C'est ce que debian fait avec la plupart des logiciels en même temps.
Avec Firefox et Thunderbird par contre, Debian est obligé d'aller plus loin encore, et de changer les logos et les noms, à cause de problèmes de licence.
Bon, j'ai au moins cette simili-solution, je peux y accéder a travers l'interface web dudit exchange. J'aurai préféré mieux ceci dit, donc si quelqu'un à encore des idées… je n'y crois pas trop mais on sait jamais.
Je suis tombé sur des gens mentionnant ce plugin ( j'aurai du le préciser je sais ) mais il n'est pas compatible avec les antiquités la qualité à l'ancienne.
De tout ce que tu as cite, le seul que je ne connais, c'est bjam. Mais globalement aucun ne tiens la route
J'ai pourtant cité des outils qui sont assez célèbres je pense. Peut-être uniquement auprès des dev C et/ou C++, ceci dit.
Par contre je me demande comment tu peux juger d'outils sans les avoir essayés?
genre detection de dependences optionnelles en cross compilation et quelques plateformes funny et tu haieras toutes tes dependences qui n'utilises pas les autotools.
Ce n'est pas parce que les autotools ne sont pas capables de supporter les autres systèmes, que ce sont les autres systèmes qui sont le problème.
Au passage, CMake générant potentiellement ( pas obligé, c'est à toi de choisir en fait ) un makefile sous linux, je ne vois pas comment il pourrait être incompatible avec les autotools, vu qu'ils intègrent GNU make.
Mais des que ca devient serieux,
Oui, la facilité de maintenance est quelque chose d'important pour moi. Après, un système comme les autotools qui ne marche que mal ( me semble qu'il marche malgré tout un peu donc… ) sur l'un des systèmes les plus populaires ( windows ), ça ne me semble pas "sérieux" comme tu dis.
J'ai beau ne pas aimer utiliser ce système, quand je choisis un outil, je le choisit en fonction du fait de ne pas être obligé d'avoir a en changer dès qu'on m'imposera a nouveau de travailler sur windows. Donc je choisit un truc portable linux/windows voire POSIX/windows quand je le peux.
Exact, il se contente de générer un fichier qui, lui, permets de compiler le projet.
C'est sûr, les autotools incluent une implémentation de make, mais bon, de la à les qualifier d'irremplaçables pour autant… il y en a d'autres, des implémentations de make.
Posté par freem .
En réponse à la dépêche Wayland et Weston 1.4.
Évalué à 1.
Dernière modification le 13 février 2014 à 14:04.
Debian est réputée pour son âge, mais il ne faut pas pousser je dirais, surtout que j'utilise les versions plus récentes ou aussi récentes que "stable".
A la louche, j'ai bien 5s sur mon desktop quand je passe d'une TTY à un Xorg ( ou vice-versa).
A l'heure de cet article ( celui auquel tu fais référence ) la confusion existait entre Wayland le protocole, et Wayland l'implémentation de référence.
Weston, le nouveau nom de Wayland l'implémentation de référence, dépend de KMS. Mais je ne suis pas sûr que ce soit le cas du protocole.
Pour OpenGL & co, c'est différent puisque le but de Wayland semble être de justement d'optimiser son usage en réduisant la quantité de fois ou les données sont transférées d'un élément (processus, driver, serveur graphique, etc) à l'autre.
Serait-ce pour ça que j'ai dit "on peut presque dire " ? Ce que je voulais dire, c'est que point de vue utilisateur, ça y ressemble ( surtout s'il s'agit d'un jeu qui a implémenté correctement la capture de la souris ), alors qu'en terme de fonctionnement interne, je sais que ça n'a rien à voir. Je ne suis pas bon, mais il y a des limites tout de même :)
Et de toute façon, je crois avoir remarqué que X n'a pas été pensé avec l'optique du multi-écran. ( je parle du moment de sa création, je sais que c'est maintenant possible )
Ca par contre, c'est un peu faux. … le windows manager, le composite manager et X ont ete merge ensemble.
Dans la FaQ de Wayland, il est dit qu'un des problèmes de X est la surabondance de fonctionnalités qui ne sont plus utiles à l'heure actuelle, et qu'il est nécessaire d'implémenter si l'on veut prétendre au titre de serveur X.
Le window manager, qui peut être composite ou non si je ne comprend pas trop mal les divers trucs que j'ai lus rapidement, est aussi un truc qui peut manifestement se coder en peu de lignes: dwm pèse moins de 2KLoC, je crois? ( Je n'émet aucun jugement quant au fait que ce soit une bonne ou une mauvaise chose, hein, je dis juste que c'est possible en peu de lignes. )
Du coup je m'imagine qu'il y a moyen que ça prenne moins de lignes de code de faire un serveur Wayland qu'un serveur X.
Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer.
Et y a t-il une quelconque raison technique qui rendrait ça impossible avec le présent protocole?
Je me trompe peut-être, mais Wayland est bien un protocole d'échange entre le serveur graphique et les applications, non? A partir de la, qu'est-ce qui empêcherait d'avoir un mécanisme d'IPC? Ce genre de choses existe depuis bien longtemps, et si Wayland finit par être réellement adopté, je doute que personne ne fera de serveur Wayland sur les autres systèmes.
En fait, je doute que Wayland ne sera implémenté que pour linux sur amd64 ( puisque tu parles du rPI notamment, je serai surpris qu'il n'y ait pas un port dans plus ou moins longtemps ) et à force d'avoir diverses implémentations, peut-être qu'une lib se dégagera?
Et bien justement, vu qu'on parle de portabilite, tu vas avoir quelques restrictions pour Wayland sur Freebsd. Avec un peu de chance tu auras un backend fbdev.
Je n'ai pas creusé très loin, mais il semble que certains essaient.
En plus, même de la diversité non portable, c'est une bonne chose. Je ne vois aucun inconvénient à avoir une alternative à X, qu'elle soit portable ou non.
Pour BSD, vu qu'il y a moyen de faire tourner Wayland sur X je crois, il y aura au minimum cette solution la, même si la personne qui à fait quelques patchs à lâché l'affaire depuis ( je n'ai pas creusé, comme je l'ai dit. ).
Je pense que Wayland est un protocole, et qu'en tant que tel, il est possible de coder ( que ce soit plus ou moins simple en fonction de la cible, c'est évident ) un serveur Wayland sur n'importe quel OS qui ait des périphériques d'entrée pointage+saisie et un périphérique de sortie type écran. Je me trompe peut-être.
Parce qu'il n'y a pas que la volonté de l'ingénieur en charge du projet, mais aussi des raisons politiques et traditionnelles, je suppose.
Ceci dit, c'est une excellente question, je la poserai*. Je mets ça sur ma TODO list mentale :p
*: je ne précise pas la date, ce serait dommage de me prendre un procès pour pub mensongère tandis que la, je peux la poser quand je serai mort héhé
J'ai en effet cité 2 ou 3 fonctionnalités de compiz-fusion, mais franchement, j'en ai autant à ce sujet pour aero de Windows vista+ ou les divers gestionnaires de fenêtres que je peux voir dans les diverses démo. ( je n'ai pas juste parlé des effets de flamme, mais aussi des coins arrondis, de la transparence, etc )
Après, je suis aussi conscient du fait que je sois un utilisateur ayant un usage très différent de la moyenne qui utilise un paradigme différent de la moyenne. Et j'accepte volontiers ma bizarrerie, loin de moi l'idée d'imposer à quiconque les TWM. Je n'ose en parler qu'aux gens ayant un minimum de culture informatique ET libre, d'ailleurs, pour garder une réputation de mecs un peu cinglé mais pas complètement ;)
Pour le fait d'utiliser le GPU plutôt que le CPU, ce n'est pas bête, sauf que je préfère un logiciel qui utilise disons, 10k cycles CPU à la seconde* que 15k cycles GPU à la seconde, d'autant que toutes mes machines n'ont pas nécessairement de GPU et que j'aime avoir un environnement très semblable d'une machine à l'autre.
Et puis, très franchement, ce que je vois quand mon gestionnaire de fenêtre bosse, j'ai plutôt l'impression que ce sont des calculs sur entiers ( genre 1920/2, pas besoin de float ni de double pour ça ). Après, c'est le rendu lui-même qui peut utiliser potentiellement opengl ( j'en vois bien l'intérêt pour claws, tiens… oupa ) en fonction de l'application ( par contre, pour redeclipse, vu que je joue en fenêtré… pourquoi pas, sauf qu'ici aussi ,le gestionnaire de fenêtre à peu de travail à effectuer: le mode fenêtré en question prend un de mes écrans en entier ;) on peut presque dire qu'il s'agit d'un mode fullscreen, au final. Presque. )
Maintenant, à voir. J'ai une certaine affinité avec l'idée derrière wayland, qui est un projet que je vois d'un très bon oeil:
_ plus spécialisé que Xorg ( ne fait qu'une chose, on peut donc espérer qu'il la fera bien. )
_ portable ( avec un peu de bol, quelqu'un finira peut-être par en faire serveur pour windows, histoire d'enrichir nos kits de survie en environnement hostile /me rêve )
_ pas de code historique oublié de tous, donc simplicité de maintenance. Moins de bugs et meilleures perfs ( mais la perf se mesure pas uniquement au sujet de la fluidité: la batterie aussi est affectée ) en seront probablement les conséquences.
_ de la diversité ( n'avoir aucune alternative est maintenant quelque chose qui me trouble… avant, c'était d'en avoir trop, mais j'y ai vite pris goût je crois. Il faut que j'aille tester debian kfreebsd un de ces 4 d'ailleurs :p )
_ avec un peu de bol, moins pénible a configurer que Xorg? je verrai quand je m'y pencherais je suppose :)
C'est juste que je me demande vraiment si l'utilisateur verra une différence, d'autant que la mode des logiciels finaux est aux bloatwares selon moi.
dkms n'est pas installé sur mes machines en général, quoique peut-être que si pour celle qui a une CG nvidia, vu que c'est un paquet recommandé, c'est possible, a vérifier. Sinon, ce n'est instantané sur ma machine de boulot* si sur mes 2 autres machines, l'une tournant avec le blob proprio nvidia, l'autre étant sur un chipset intel.
Mais c'était aussi "rapide" de mémoire avec nouveau…
Dkms permets d'accélérer ça? J'admets avoir une assez ( très ) mauvaise compréhension du kernel linux ( et de tous les autres en fait, il me faudrait vraiment y pallier un jour, sauf que voila, je n'ai jamais trouvé de truc très accessibles à ce sujet. Logique en même temps je dirais )
Sans réfléchir, je peux en citer 2, bjam ( parce que j'utilise quelques lib boost et ai du les compiler sous win a une époque ) et cmake ( que j'utilise malgré une dépendance a emacsen ;) ) , sachant que je n'ai vraiment regardé ( en lisant les fichiers à écrire que d'autres ont fait dans leurs projets ) que du côté des traditionnels autotools et de cmake, et la différence est claire: cmake, sans rien en connaître, tu peux détecter et corriger un bug ( j'en ai fait l'expérience dans le CMake d'openmw, une sombre histoire de version de boost qui n'était pas la bonne. Depuis, je suis vendu. ) . autotools… tu ouvres le fichier, tu comprend direct qu'il te faut apprendre un tas de nouveaux trucs avant de pouvoir t'en servir.
Sinon, il y a scons qui semble réputé aussi.
Je me demande si cmake et scons ( bjam j'en doute, au fond a part boost je ne sais pas si quelqu'un s'en sert ) sont utilisables sous android? En tout cas, une recherche rapide trouve des scripts permettant de compiler pour android, ce qui ne corrobore pas tes propos.
Ah, il y a aussi code::blocks, qui potentiellement pourrais compiler pour android, malgré que je ne l'utilise plus ( et les fichiers de config sont en xml en plus… erk ).
Bref, je suis sûr qu'il y a le choix.
Ceci dit, je n'ai jamais testé la compilation sous android, ou n'importe quel autre <>phone, et vu mon opinion au sujet de ces jouets, ça n'arrivera pas de sitôt, sauf raison professionnelle.
Donc si tu les as testés sous android, je suis preneur de ton retour :)
[^] # Re: C'est la vie...
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 3.
Vendredi ou pas, je m'en moque. De toute façon, je passe aléatoirement donc bon…
Cependant, j'ai lu à plusieurs reprise ce point précis: deb à été créé plusieurs années avant rpm, mais rpm à été """sacré""" format universel des package linux.
Mais je n'ai jamais vu la moindre raison technique ( oui, je sais, on est lundi, pas trolldi… ) expliquant cette raison.
Donc, ma question est simple: y a t-il une seule raison objective ayant permis d'élire rpm comme format universel?
Sachant que, bien sûr, deb à ses défauts, par exemple il est impossible d'installer un deb en userspace avec les outils standard. Mais si rpm à le même problème, alors… bref.
Une raison technique derrière ce choix, ou c'est encore une question de blé?
[^] # Re: NIH ?
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 1.
Ma foi…
Mon opinion sur le sujet est très simple.
Les auteurs d'un logiciels sont en droit de refuser aux autres le droit de le modifier. Ca ne me pose pas plus de souci que ça.
Pourquoi ça ne me pose pas plus de souci que ça?
C'est simple: si quelqu'un n'est pas d'accord, il n'a qu'a faire mieux. Tant qu'il n'y a pas de copyright stupide empêchant la compétition, et tant que les standards sont suivis alors qu'ils n'empêchent pas le progrès, il n'y a pas de mal.
Le point étant que, même si j'aime l'idée du libre et même si je lui reconnaît nombre de qualité, je lui admets surtout la qualité de choisir d'être libéré ou pas. La liberté implique la prise de risque, et tout le monde n'est pas prêt à acheter sa liberté dans ces conditions. Conditions que, personnellement, j'accepte avec des compromis, puisque j'utilise moi-même des logiciels non libres ( flash, opera et le pilote nvidia. Oui, l'un d'entre eux à une alternative """libre""" populaire et 100% fonctionnelle, et de nombreuses alternatives libres tout court. Mais justement, je l'ai choisi en toute liberté de choix et en comprenant le contrat que j'ai signé numériquement, donc je suis libre. Je suis également libre de me passer de vidéos sur le net et d'utiliser pleinement le GPU de ma tour… je l'ai déjà fait.)
[^] # Re: OpenRC
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 0.
Permets moi de rebondir sur ta réponse, et de demander ce qu'apporte et enlève exactement openRC à 1) sysVinit et 2) systemd.
Du peu que je suppose avoir compris du peu que j'ai lu ( ça fait beaucoup de peu, mais j'ai encore peur de surestimer l'état de mes connaissances… imagines le travail :) ) :
_ openRC conserve la complexité d'écriture de scripts de sysVinit ( j'entends par la que la syntaxe utilisée est celle de sh, ce qui est complexe du point de vue utilisateur, pas de celui du système )
_ mais openRC permets de paralléliser les tâches ( comme pour systemd ) . Chose qui d'ailleurs m'intrigue vu que j'ai lu diverses allégations laissant supposer que sysVinit en serait aussi capable ( on parle de script shell dans les 2 cas si je ne m'abuse, donc ça ne m'a pas semblé irréaliste )
_ tout en n' ( emphase sur la négation ) ayant pas les tonnes de dépendances de systemd à des modules non vitaux pour un OS minimal ( c'est à dire, pas de dépendance à dbus ou logind, par exemple ).
[^] # Re: NIH ?
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 3.
Mouai.
J'aurai plutôt dit qu'il n'y a pas de NIH ici, systemd tout comme upstart apportent des fonctionnalités et une architecture que n'a pas sysVinit.
Le NIH, c'est juste réimplémenter un outil ayant les mêmes fonctionnalités qu'une alternative non-contraignante ( par rapport au nouveau projet, et, oui, cela inclue les problème de licence. ) déjà existante propose.
[^] # Re: NIH ?
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 0. Dernière modification le 17 février 2014 à 20:29.
D'un autre côté, ne pas mettre de CLA, c'est une ""erreur"" ( double guillemets, vous avez vu? ) que divers projets ont faits, projets qui ont ensuite dû contacter les contributeurs 1 par 1 pour essayer d'unifier les licences.
Dans un univers ( impitoyable genre dallas ) tel que l'open source, ce genre de choses ( ne pas imposer de CLA ) peut tuer un projet sur le long terme, tandis qu'avec un CLA, les choses sont claires dès le début, contribue qui veut, forke qui veut, ce qui assure que l'équipe du projet sera toujours apte à faire avancer le projet dans la direction qu'elle souhaite.
Après… c'est sûr, un CLA sans conditions, c'est dangereux pour la liberté du projet, mais on sort clairement du problème généraliste du CLA pour entrer dans la spécialisation du CLA potentiellement privatif.
PS: j'ai hésité sur le terme privatif, mais à force je ne sais plus lequel entre privateur et privatif est réellement français…
[^] # Re: NIH ?
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 2.
Je vais sûrement t'accompagner dans le karma négatif, mais j'admets que ça ne me dérange pas.
Je voulais juste te remercier d'être aussi insistant dans l'art de foutre des coups de pieds dans les fourmilières et de casser les consensus. Le bouton "pertinent" ne le permettant pas quand on arrive à un stade de moinssage aussi important, je me permets ce commentaire inutile.
[^] # Re: fin de l'histoire ?
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 1.
Hum…
Désolé, mais le nombre de pulse machin sur mon système est inférieur à celui des modules systemd. Ou du moins, plus simple à rendre tel:
$ aptitude search ~i |grep pulse
i A libpulse-dev - PulseAudio client development headers and
i A libpulse-mainloop-glib0 - bibliothèques clients PulseAudio - gestion
i A libpulse0 - bibliothèques clientes PulseAudio
A noter que les raisons d'installation de ces paquets sont, pour les 2 1ers, la lib de dev de SDL, et pour le 3eme, mplayer.
Systemd, en revanche, c'est plus chiant:
mpd en dépend ( libsystemd-daemon0 )
dbus en dépend ( libsystemd-journal0 ainsi que libsystemd-login0 et pour virer dbus, sans perdre de fonctionnalités, bon courage! )
Bref, rien de comparable. Le 1er ( PA ) ne squatte quasiment que via certaines lib de dev, tandis que l'autre s'incruste au travers d'outils centraux du système.
[^] # Re: Gestionnaire de fenêtres léger
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 1.
Compte tenu du fait qu'on parle d'un
logicielprotocole libre, ce n'est pas à la seule volonté de l'équipe dewestonwayland.[^] # Re: Grosse fatigue
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 0.
Je suis à la fois d'accord et pas d'accord au sujet du vectoriel.
Le vectoriel me semble plus adapté, clairement, parce que plus léger sur le réseau. Enfin, plus léger… si et seulement si on essaie pas de transmettre des photos! Pour des graphismes simples, du genre de ceux du thème qu'on avait du temps de windows 98.
Si on se concentrait sur des thèmes fonctionnels plutôt qu'esthétiques, alors le vectoriel serait le plus adapté ( et par forcément le SVG, qui est hyper verbeux à cause de son héritage XML. Je ne sais pas si d'autres format vectoriel plus efficaces existent? ), léger sur le réseau pour une surcharge CPU/GPU raisonnable.
En fait, c'est comme pour tout: il y a plusieurs solutions, chacune étant plus efficace en fonction de la situation. RDP doit probablement faire de la compression et sélection de zone ( à vous lire ), et donc plus efficace pour un environnement utilisant des graphismes de plus haute qualité, alors que le vectoriel serait plus efficace pour un thème épuré.
[^] # Re: Grosse fatigue
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 6.
La conséquence est qu'avec wayland, il faudra obligatoirement utiliser un logiciel tiers pour de l'affichage distant.
D'un autre côté, ce n'était pas le but de wayland de base, qui me semble plus cibler l'ordinateur personnel ( j'inclue dans ce terme les trucphones et les ordinateurs de voiture par exemple ) au lieu des serveurs d'applications.
X me semble plus conçu pour les serveurs d'applications, c'est à dire pour les contraintes de coût d'il y a 30 ans, ou les ordinateurs étaient tellement coûteux qu'il était plus économique d'avoir un serveur d'application auquel se connectent des terminaux ( du genre incapables de faire quoique ce soit sans réseau. Nos machines actuelles, même si elles sont souvent uniquement utilisées avec un stupide navigateur internet, restent capables de faire des choses sans internet. C'est juste leurs utilisateurs qui n'en sont plus trop capables. ).
A l'heure actuelle, n'importe quel gadget est assez puissant pour faire tourner les applications par lui-même, donc les serveurs d'applications n'ont plus un très grand intérêt, et c'est probablement pour ça que l'équipe de wayland n'a pas voulu s'embêter avec cette fonctionnalité. Enfin, c'est ce que je suppose.
Et puis, VNC existe et est plus efficace ( il paraît, je n'ai jamais testé personnellement ) qu'utiliser Xorg directement.
[^] # Re: Extensions
Posté par freem . En réponse au journal Firefox va afficher de la publicité. Évalué à 3.
J'adore l'idée des extensions qui enlèvent des choses :D
[^] # Re: Contexte
Posté par freem . En réponse au journal Firefox va afficher de la publicité. Évalué à 2.
C'est ce que debian fait avec la plupart des logiciels en même temps.
Avec Firefox et Thunderbird par contre, Debian est obligé d'aller plus loin encore, et de changer les logos et les noms, à cause de problèmes de licence.
# interface ouaib
Posté par freem . En réponse au message accéder a des calendriers partagés gérés par exchange 2003. Évalué à 1. Dernière modification le 13 février 2014 à 14:26.
Bon, j'ai au moins cette simili-solution, je peux y accéder a travers l'interface web dudit exchange. J'aurai préféré mieux ceci dit, donc si quelqu'un à encore des idées… je n'y crois pas trop mais on sait jamais.
PS: merci pour les réponses.
[^] # Re: Il y a une extension qui fait ça…
Posté par freem . En réponse au message accéder a des calendriers partagés gérés par exchange 2003. Évalué à 1.
Comme j'ai répondu à l'autre réponse, ce plugin ne semble pas fonctionner pour exchange 2003, malheureusement.
[^] # Re: thunderbird + lightning + plugin exchange
Posté par freem . En réponse au message accéder a des calendriers partagés gérés par exchange 2003. Évalué à 1.
Je suis tombé sur des gens mentionnant ce plugin ( j'aurai du le préciser je sais ) mais il n'est pas compatible avec
les antiquitésla qualité à l'ancienne.[^] # Re: En fait la discussion continue
Posté par freem . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 1.
J'ai pourtant cité des outils qui sont assez célèbres je pense. Peut-être uniquement auprès des dev C et/ou C++, ceci dit.
Par contre je me demande comment tu peux juger d'outils sans les avoir essayés?
Ce n'est pas parce que les autotools ne sont pas capables de supporter les autres systèmes, que ce sont les autres systèmes qui sont le problème.
Au passage, CMake générant potentiellement ( pas obligé, c'est à toi de choisir en fait ) un makefile sous linux, je ne vois pas comment il pourrait être incompatible avec les autotools, vu qu'ils intègrent GNU make.
Oui, la facilité de maintenance est quelque chose d'important pour moi. Après, un système comme les autotools qui ne marche que mal ( me semble qu'il marche malgré tout un peu donc… ) sur l'un des systèmes les plus populaires ( windows ), ça ne me semble pas "sérieux" comme tu dis.
J'ai beau ne pas aimer utiliser ce système, quand je choisis un outil, je le choisit en fonction du fait de ne pas être obligé d'avoir a en changer dès qu'on m'imposera a nouveau de travailler sur windows. Donc je choisit un truc portable linux/windows voire POSIX/windows quand je le peux.
[^] # Re: En fait la discussion continue
Posté par freem . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 1.
Exact, il se contente de générer un fichier qui, lui, permets de compiler le projet.
C'est sûr, les autotools incluent une implémentation de make, mais bon, de la à les qualifier d'irremplaçables pour autant… il y en a d'autres, des implémentations de make.
[^] # Re: Bien...bien...bien
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 1. Dernière modification le 13 février 2014 à 14:04.
Debian est réputée pour son âge, mais il ne faut pas pousser je dirais, surtout que j'utilise les versions plus récentes ou aussi récentes que "stable".
A la louche, j'ai bien 5s sur mon desktop quand je passe d'une TTY à un Xorg ( ou vice-versa).
[^] # Re: Pilotes propriétaires
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 1.
A l'heure de cet article ( celui auquel tu fais référence ) la confusion existait entre Wayland le protocole, et Wayland l'implémentation de référence.
Weston, le nouveau nom de Wayland l'implémentation de référence, dépend de KMS. Mais je ne suis pas sûr que ce soit le cas du protocole.
Pour OpenGL & co, c'est différent puisque le but de Wayland semble être de justement d'optimiser son usage en réduisant la quantité de fois ou les données sont transférées d'un élément (processus, driver, serveur graphique, etc) à l'autre.
Mais je peux me tromper.
[^] # Re: Gestionnaire de fenêtres léger
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 1.
Serait-ce pour ça que j'ai dit "on peut presque dire " ? Ce que je voulais dire, c'est que point de vue utilisateur, ça y ressemble ( surtout s'il s'agit d'un jeu qui a implémenté correctement la capture de la souris ), alors qu'en terme de fonctionnement interne, je sais que ça n'a rien à voir. Je ne suis pas bon, mais il y a des limites tout de même :)
Et de toute façon, je crois avoir remarqué que X n'a pas été pensé avec l'optique du multi-écran. ( je parle du moment de sa création, je sais que c'est maintenant possible )
Dans la FaQ de Wayland, il est dit qu'un des problèmes de X est la surabondance de fonctionnalités qui ne sont plus utiles à l'heure actuelle, et qu'il est nécessaire d'implémenter si l'on veut prétendre au titre de serveur X.
Le window manager, qui peut être composite ou non si je ne comprend pas trop mal les divers trucs que j'ai lus rapidement, est aussi un truc qui peut manifestement se coder en peu de lignes: dwm pèse moins de 2KLoC, je crois? ( Je n'émet aucun jugement quant au fait que ce soit une bonne ou une mauvaise chose, hein, je dis juste que c'est possible en peu de lignes. )
Du coup je m'imagine qu'il y a moyen que ça prenne moins de lignes de code de faire un serveur Wayland qu'un serveur X.
Et y a t-il une quelconque raison technique qui rendrait ça impossible avec le présent protocole?
Je me trompe peut-être, mais Wayland est bien un protocole d'échange entre le serveur graphique et les applications, non? A partir de la, qu'est-ce qui empêcherait d'avoir un mécanisme d'IPC? Ce genre de choses existe depuis bien longtemps, et si Wayland finit par être réellement adopté, je doute que personne ne fera de serveur Wayland sur les autres systèmes.
En fait, je doute que Wayland ne sera implémenté que pour linux sur amd64 ( puisque tu parles du rPI notamment, je serai surpris qu'il n'y ait pas un port dans plus ou moins longtemps ) et à force d'avoir diverses implémentations, peut-être qu'une lib se dégagera?
Je n'ai pas creusé très loin, mais il semble que certains essaient.
En plus, même de la diversité non portable, c'est une bonne chose. Je ne vois aucun inconvénient à avoir une alternative à X, qu'elle soit portable ou non.
Pour BSD, vu qu'il y a moyen de faire tourner Wayland sur X je crois, il y aura au minimum cette solution la, même si la personne qui à fait quelques patchs à lâché l'affaire depuis ( je n'ai pas creusé, comme je l'ai dit. ).
Je pense que Wayland est un protocole, et qu'en tant que tel, il est possible de coder ( que ce soit plus ou moins simple en fonction de la cible, c'est évident ) un serveur Wayland sur n'importe quel OS qui ait des périphériques d'entrée pointage+saisie et un périphérique de sortie type écran. Je me trompe peut-être.
[^] # Re: Comparaison foireuse
Posté par freem . En réponse au journal Pourquoi les jeux vidéos devraient entrer dans le domaine public. Évalué à 1.
Parce qu'il n'y a pas que la volonté de l'ingénieur en charge du projet, mais aussi des raisons politiques et traditionnelles, je suppose.
Ceci dit, c'est une excellente question, je la poserai*. Je mets ça sur ma TODO list mentale :p
*: je ne précise pas la date, ce serait dommage de me prendre un procès pour pub mensongère tandis que la, je peux la poser quand je serai mort héhé
[^] # Re: Gestionnaire de fenêtres léger
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à -1.
J'ai en effet cité 2 ou 3 fonctionnalités de compiz-fusion, mais franchement, j'en ai autant à ce sujet pour aero de Windows vista+ ou les divers gestionnaires de fenêtres que je peux voir dans les diverses démo. ( je n'ai pas juste parlé des effets de flamme, mais aussi des coins arrondis, de la transparence, etc )
Après, je suis aussi conscient du fait que je sois un utilisateur ayant un usage très différent de la moyenne qui utilise un paradigme différent de la moyenne. Et j'accepte volontiers ma bizarrerie, loin de moi l'idée d'imposer à quiconque les TWM. Je n'ose en parler qu'aux gens ayant un minimum de culture informatique ET libre, d'ailleurs, pour garder une réputation de mecs un peu cinglé mais pas complètement ;)
Pour le fait d'utiliser le GPU plutôt que le CPU, ce n'est pas bête, sauf que je préfère un logiciel qui utilise disons, 10k cycles CPU à la seconde* que 15k cycles GPU à la seconde, d'autant que toutes mes machines n'ont pas nécessairement de GPU et que j'aime avoir un environnement très semblable d'une machine à l'autre.
Et puis, très franchement, ce que je vois quand mon gestionnaire de fenêtre bosse, j'ai plutôt l'impression que ce sont des calculs sur entiers ( genre 1920/2, pas besoin de float ni de double pour ça ). Après, c'est le rendu lui-même qui peut utiliser potentiellement opengl ( j'en vois bien l'intérêt pour claws, tiens… oupa ) en fonction de l'application ( par contre, pour redeclipse, vu que je joue en fenêtré… pourquoi pas, sauf qu'ici aussi ,le gestionnaire de fenêtre à peu de travail à effectuer: le mode fenêtré en question prend un de mes écrans en entier ;) on peut presque dire qu'il s'agit d'un mode fullscreen, au final. Presque. )
Maintenant, à voir. J'ai une certaine affinité avec l'idée derrière wayland, qui est un projet que je vois d'un très bon oeil:
_ plus spécialisé que Xorg ( ne fait qu'une chose, on peut donc espérer qu'il la fera bien. )
_ portable ( avec un peu de bol, quelqu'un finira peut-être par en faire serveur pour windows, histoire d'enrichir nos kits de survie en environnement hostile /me rêve )
_ pas de code historique oublié de tous, donc simplicité de maintenance. Moins de bugs et meilleures perfs ( mais la perf se mesure pas uniquement au sujet de la fluidité: la batterie aussi est affectée ) en seront probablement les conséquences.
_ de la diversité ( n'avoir aucune alternative est maintenant quelque chose qui me trouble… avant, c'était d'en avoir trop, mais j'y ai vite pris goût je crois. Il faut que j'aille tester debian kfreebsd un de ces 4 d'ailleurs :p )
_ avec un peu de bol, moins pénible a configurer que Xorg? je verrai quand je m'y pencherais je suppose :)
C'est juste que je me demande vraiment si l'utilisateur verra une différence, d'autant que la mode des logiciels finaux est aux bloatwares selon moi.
[^] # Re: Bien...bien...bien
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 1.
dkms n'est pas installé sur mes machines en général, quoique peut-être que si pour celle qui a une CG nvidia, vu que c'est un paquet recommandé, c'est possible, a vérifier. Sinon, ce n'est instantané sur ma machine de boulot* si sur mes 2 autres machines, l'une tournant avec le blob proprio nvidia, l'autre étant sur un chipset intel.
Mais c'était aussi "rapide" de mémoire avec nouveau…
Dkms permets d'accélérer ça? J'admets avoir une assez ( très ) mauvaise compréhension du kernel linux ( et de tous les autres en fait, il me faudrait vraiment y pallier un jour, sauf que voila, je n'ai jamais trouvé de truc très accessibles à ce sujet. Logique en même temps je dirais )
*:
$ lspci |grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
[^] # Re: Grosse fatigue
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 4.
Surtout la dernière mouture :D
[^] # Re: En fait la discussion continue
Posté par freem . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à -1.
Tu ne sais pas par quoi remplacer les auto-tools?
Sans réfléchir, je peux en citer 2, bjam ( parce que j'utilise quelques lib boost et ai du les compiler sous win a une époque ) et cmake ( que j'utilise malgré une dépendance a emacsen ;) ) , sachant que je n'ai vraiment regardé ( en lisant les fichiers à écrire que d'autres ont fait dans leurs projets ) que du côté des traditionnels autotools et de cmake, et la différence est claire: cmake, sans rien en connaître, tu peux détecter et corriger un bug ( j'en ai fait l'expérience dans le CMake d'openmw, une sombre histoire de version de boost qui n'était pas la bonne. Depuis, je suis vendu. ) . autotools… tu ouvres le fichier, tu comprend direct qu'il te faut apprendre un tas de nouveaux trucs avant de pouvoir t'en servir.
Sinon, il y a scons qui semble réputé aussi.
Je me demande si cmake et scons ( bjam j'en doute, au fond a part boost je ne sais pas si quelqu'un s'en sert ) sont utilisables sous android? En tout cas, une recherche rapide trouve des scripts permettant de compiler pour android, ce qui ne corrobore pas tes propos.
Ah, il y a aussi code::blocks, qui potentiellement pourrais compiler pour android, malgré que je ne l'utilise plus ( et les fichiers de config sont en xml en plus… erk ).
Bref, je suis sûr qu'il y a le choix.
Ceci dit, je n'ai jamais testé la compilation sous android, ou n'importe quel autre <>phone, et vu mon opinion au sujet de ces jouets, ça n'arrivera pas de sitôt, sauf raison professionnelle.
Donc si tu les as testés sous android, je suis preneur de ton retour :)