Enjolras a écrit 295 commentaires

C'est pas un commentaire à la con, c'est un commentaire pour dire que j'en ai complètement marre des gens immatures qui prennent tout pour eux et qui sont incapable de laisser une communauté fonctionner en tant que communauté.

Ce journal est un ramassis d'attaques personnelles où l'auteur, sous couvert de synthèse du problème, ramène tout à lui et à sa frustration due au faut que certains ne pensent pas comme lui.

En outre, les questions de "démocratie" me font bien rire. Ce n'est pas parce que Votre opinion n'est pas acceptée que le processus n'est pas démocratique. Ce qui compte c'est les personnes qui s'expriment. Et ce genre d'expression a sa place dans le suivi.

Enfin je pense qu'il y a mieux à faire qu'écrire un flameware dans ce genre, par exemple en écrivant un autre pacth qui prend en compte les idées des autres gens.

…ça doit encore être la faute des shadocks.

Je pense que tu n'as pas compris. La liberté de choix existe, puisqu'on PEUT faire un fork. Si le projet réussi, ça prouve qu'il existe réellement des gens qui ne supportent pas gnome3. S'il échoue, ça prouve que c'est juste quelques gricnheux incapables de sortir de leurs habitudes, et qui plus est, pas assez motivés/bons pour assurer un fork.

Je pense que vous racontez quand même pas mals d'âneries à propos de chakra…
Chakra n'as plus grand chose à voir avec Arch, hormis sous système de paquet.
Personne ne dit que ubuntu c'est comme debian, de même Arch et Chakra sont devenues bien différentes…
Il est aussi simple d'utiliser Chakra que Kubuntu, ou alors j'aimerais bien qu'on m'explique pourquoie ce n'est pas le cas.
Il y a des outils graphiques pour la gestion des paquets et pour le système, et c'est une distribution robuste qui ne nécéssite aucune connaissance pour un usage simple

Ou sinon, on peut utiliser un Wm. Au pif :
awesome, dwm, wmi, openbox, blackbox, fluxbox, fvwm, subtle, wmfs, ratpoison, xmonad,sawfish, stump wm, window maker, etc, etc, etc.

Ne t'inquiètes, Linux en PHP, ça va arriver bientôt. Ça fera tourner Gnome-shell en Javascript, avec un lecteur audio en javascript builtin dans Firefox qui utilisera des codecs en javascripts. Enfin, la virtualisation se fera dans firefox, en javascript grâce à Bellard. vive les technos Web, le C, c'est surfait.
(ah mais wait, j'y pense, en quoi vas on écrire tout ces interpréteurs ?)

Si, mais les applis natives ne sont pas en HTML/CSS/javascript.
En fait, ils ne veulent pas "reproduire" les apis noyaux, ils veulent juste faire des bindings si je comprends bien.

C'est une très bonne question ça, et ils n'y répondent pas dans la FAQ.
De ce qu'on peut lire :

the updater-binary built by CyanogenMod has been observed to corrupt the /system filesystem of the Galaxy S II when applying an update.zip

Ah, ils doivent partir d'Android/Fennec alors.

Start porting gecko to directly use native libs instead of java wrappers. Big project.
Hmm, au fond, ils veulent le faire tourner sur un OS posix ?

Linux a priori, pour ce qui est de la libc je sais pas…

    firefox -P -no-remote

Excuse moi, mais là je ne te suis pas. Pourquoi l'utilisateur final as-t-il besoin de savoir ça ?
Le devellopeur web a besoin d'un profiler javascrit et d'une console de débogage. Le dévellopeur Firefox sait utiliser about:memory, et les outils adéquats.

Et ùême si l'utilisateur avait besoin de cette info, je ne vois absolument pas en quoi ça devrait être implémenté DANS le navigateur. C'est le rôle de l'OS ça. Alors d'accord, l'OS ne rapprorte pas les temps de calcul per-thread et les thread ne sont pas nommés. Mais c'est pas un problème de FF.

> et de prévu un gestion multi-comptes du navigateur, de la synchro. [...] Ça c'est de vrai évolutions tout de même.

Ah tu veux dire comme firefox ?

Enjolras, parce que Firefox c'est bien aussi.

Donc pour toi quand tu veux afficher une image dans un onglet, image qui est traitée par un autre thread puis mise dans un framebuffer dans la mémoire paratgée et affichée par ton thread à l'écran, tu appelles le framebuffer et les variables nécessaires allouée sur le tas "un cache" ?

c'est de ça qu'on parle là... Suivant ta définition, le tas est donc un cache fondamentalement. Intéressant...

J'aimerais bien qu'on m'explique le rapport entre "cache" et systeme concurent à mémoire partagée.

On parle pas de mécanisme complexe, on parle de thread vs processus. Quand tu fais un thread, tu peux le join en désallouant sa mémoire. Sinon c'est que t'as des leaks. Et, compter sur la fermeture du processus pour cleaner les leaks c'est une politique de l'autruche. je trouve ça complétement con.

Politique de l'autruche... Firefox n'est pas dev par des Programmeurs java à 10 sous.

Plus les améliorations stables sont disponibles simplement et rapidement dans mon OS, plus je suis content. C'est pas parce qu'il n'y a pas de new features qu'il n'y a pas de changement. La preuve : ici
D'ailleurs qui se pleint du cycle de release de Linux ? hein ?

Non, le seul inconvénient que j'y vois, c'est que les gens vont se lasser d'écrire des dépêches à chaque sortie, et on ne pourra plus troller.

Parce que les rolling release, c'est bien.

je fais juste remarquer que ce n'est pas forcément un modèle de confiance coherént ?
A quand des extensions signées ?

Enjolras, pour les Archers qu'on a traumatisé avec la sécurité.

Sauf que ça pose un problème sous les distros linux.
Que ce soit addblock, le pack langue français ou noscripts, que j'avais installés grâce au sublime gestionnaire de paquet de ma distro(pacman, pour ne pas le citer), ils ont tous été désactivés par défaut. Mais c'est des sources-tierces trusted...

Sauf qu'un logiciel sain n'a pas besoin de plusieurs process. Un processus par session, oui ça peut être utile, pour pouvoir par exemple avoir des instances avec des paramètres différents. (par session, j'entends deux sessions d'un même profil, par exemple avec et sans navigation privée)

Mais à quoi bon séparer les fonctionnalités dans différents pid ? ça augmente énormément l'overhead du à l'IPC, alors qu'on peut simplement utiliser des méchanismes de message-passing éprouvés dans un environnement parallélisé à mémoire partégée. Comme un bon scheduler ordonnance bien les threads, pas de problème, sans compter qu'un "ordonnanceur" userspace dans le programme peut s'y rajouter (aka mettre certains threads idle en fonctions de certains critères) qui a une meilleure vision du fonctionnement interne.

En outre, les capabilities linux (et POSIX aussi il me sembnle) sont des attributs "per thread", ce qui permet de mettre en place un modèle de sécurité cohérent. Pour ce qui est des crashs, bah de toute manière, si le coeur du logiciel crash, tout crash tu n'y peux rien. Et il vaut mieux travailler à la stabilité globale, gérer mieux les exceptions, ou même écrire un analyseur statique pour javascript que passer du temps à jouer à l'autruche en tentant de minimiser les dégats.

Alors non, le multi-process n'est pas du tout en faveur de chrome.

the public stable release was on December 11, 2008.

3 ans de retard dis tu ? intéressant. Chrome, le navigateur qui nourissait les trolls avant même d'exister !

Au pire, il y a GTK :>.

Salut,
Ce d'expèrience, je peux te dire que beaucoup de paquets AUR compilent sous ARM. C'est juste que les guidelines t'autorisent à mettre dans arch=( ) uniquement les architectures que tu as testé, et que archlinux ne supporte pas officiellement arm. Mais en réalité, rien ne t'empeche d'utiliser arm. Les problèmes que tu rencontreras seront essentiellement upstream, avec du code non portable ou x86 spécifique.

Mais c'est ça qui est drôle. Pourquoi viendrait-on ici sinon ? Les news ? autant lire les changelogs. D'ailleurs les notes négatives et moi, on est de grands amis \o/.

Je suis tout à fait d'accord, et encore une fois il ne faut pas généraliser, ce genre de personnes est minoritaire. Cependant, certains font du BSD parce qu'ils aiment BSD, et non la licence BSD.

Ce sectarisme devient lassant à la longue ! Il serait temps que les différents membres du monde de l'openSource apprennent à partager. Et non, la communauté BSD n'est pas la seule en cause ! Il suffit de lire régulièrement les commentaires du présent site pour s'en rendre compte, ou des flamewares entre distributions/OS ont lieu régulièrement.

Quant à savoir pourquoi certains membres de la communauté *BSD sont aigris, cela se comprend aisément. Essayons de se mettre à la place de ces personnes.
Notons déjà le manque de reconnaissance de la dite communauté. Il ne faut pas oublier qu'elle a une contribution non négligeable dans le monde du libre. Et ne récolte en retour que moqueries sur le prétendu retards de ses logiciels, ou l'absence de fonctionnalité, voire un simple "linux caymieux.".

Vous me direz que les trolls et les moqueries, ça s'ignore. Je vous l'accorde entièrement. Mais que dire de l'abandon par de grands noms du LL de la portabilité vers ce systemes (pourtant POSIXs. !) ? Citons les DE qui se tournent de plus en plus vers des dépendances à udev ou systemd. Après on peut débattre du manque de standards dans ces domaines mais c'est une autre histoire.

Enfin, en ce qui concerne la licence, il y a de quoi être aigri parfois quand on voit son code passer sous GPL et quand on n'est plus en mesure d'en récupérer les améliorations. Même si c'est justement le propre de la licence BSD de le permettre.

Malgrès tout, ces gueguerres intestines sont idiotes, et je pense que plus de collaborations serait bien fructueux pour les deux parties. Quant à sigma_g, je pense que l'accuser de Troll, c'est faire preuve d'une légère mauvaise fois, pour ce qui est de l'incompétence, ce n'est pas à moi de juger.