Je pense que le fait qu'il n'y presque (il existe de rares forks de firefox) que la mofo qui utilise gecko joue aussi: moins de contributeurs. Reste maintenant à déterminer pourquoi tant d'autres projets préfèrent webkit à gecko…
il doit dès le départ initialiser beaucoup de choses pour que la navigation soit opérande (la gestion de la mémoire par exemple qui est très complexe)
Genre… la gestion de la mémoire, toutes les applications natives le font hein… avec plus ou moins de bonheur, certes.
A moins que, comme certains développeurs de jeux vidéo, FF ne fasse que de gros malloc et gère ensuite lui-même les blocs mémoire (surcharge de new et delete en C++, détournement de *alloc et free en C et C++ pour qu'ils pointent vers des fonctions custom)?
Je serai surpris (parce que l'augmentation de la consommation mémoire de FF me semble trop douce pour ce type de modèle, à moins que les chunks ne soient vraiment petits, mais je reconnais n'avoir pas creusé la question), mais pourquoi pas (et puis, vue la quantité de parsing qu'il doit gérer, ce ne serait pas débile).
Sans compter qu'il faut charger l'historique et les marques pages
C'est vrai, tous les navigateurs ne le font pas. J'en vois au moins… 1 seul en fait (uzbl, parce que le but est d'être minimaliste). Même dillo et netsurf le font (mais pas de JS, nous sommes d'accord).
Et Firefox aussi doit identifier certains éléments matériels pour savoir s'il peut activer des choses comme l'accélération matérielle pour WebGL ou les codecs vidéo.
Je doute qu'il implémente des pilotes graphiques. A mon avis, il fait comme tout le monde: il demande à l'os quelle version d'oGL est dispo, et ça ne prend pas tant de temps que ça (pas rapide d'initialiser un contexte opengl à première vue, ok, mais on est loin d'expliquer un temps de plusieurs secondes avec ça).
Le pire, c'est qu'au fond je suis d'accord avec toi: un browser, c'est complexe. Ceci dit, tu sembles chercher la petite bête pour défendre à tout prix firefox.
Personnellement, je me pose juste les questions suivantes: Haiku utilise une vieille version de webkit.
Quid du respect de la chiée de nouveaux standards de plus en plus complexes apparus depuis?
Quid des sandbox?
Firefox et les browsers multi-onglets que je connais tendent à avoir plusieurs processus et non threads pour sandboxer et éviter qu'un crash d'un onglet ne ferme le brouteur. Et celui de Haiku? Lancer un processus par page (si ce n'est plus), c'est autrement plus lourd que lancer 1 thread par page…
Bref, oui, il y a des raisons au "long" démarrage de firefox (j'ai vu pire perso), et il est probable que ça pourrait être amélioré (le code est pas tout neuf non plus, je ne serai pas surpris qu'il y ait plus que quelques dizaines de KLoc de dette technique, après tout l'origine date des années 90 hein) mais je m'interroge sur comment Haiku serait plus rapide en offrant la même sécurité et robustesse, en se basant sur du code obsolète…
Donc, il y a un contexte qui est initialisé quand on charge la lib, et qui référence les instances de fenêtres, les nettoyant quand elles se ferment? Admettons que ce soit une bonne idée (c'est la technique que semblait utiliser glfw2, abandonnée par la v3 étrangement quand ils semblent avoir ajouté le support de multi-fenêtrage. Bon, la sdl semble toujours faire ça, mais force m'est de reconnaître que les applications SDL ne s'interfacent pas super bien avec le reste de mon système), pourquoi dans ce cas utiliser des pointeurs nus et non des objets réels?
Ça éviterait que quelqu'un ne soit tenté de delete… d'ailleurs, si quelqu'un le faisait, il se passerait quoi?
Pour le reste, personnellement j'aime bien redmine, mais je pense que c'est une question de goûts et d'habitude.
Accessoirement, redmine n'est pas un simple bugtracker mais une forge logicielle, donc offre potentiellement des fonctionnalités dont tu n'auras pas besoin (intégration d'outils de gestion de version (git, svn, cvs, bazaar, mercurial, etc), forum, wiki et j'en oublie).
En fait, ce sera difficile de te conseiller si tu ne nous dis pas pourquoi bugzilla ne te vas pas.
Ce site est juste génial pour comprendre les outils UNIX quand on les découvre.
Je t'avoue ne pas maîtriser awk, mais je pense qu'en passant un peu de temps à lire la bonne section, tu devrais comprendre ce bout de code.
"Sources: Many readers have asked that I provide third party citations to ‘prove’ the NSA identified Satoshi using stylometry. Unfortunately, I cannot as I haven’t read this anywhere else—hence the reason I wrote this post. I’m not trying to convince the reader of anything, instead my goal is to share the information I received and make the reader aware of the possibility that the NSA can easily determine the authorship of any email through the use of their various sources, methods, and resources."
Le mec il a une source récursive en fait :D attention au dépassement de pile hein, ça peut faire mal ces bêtes la…
Posté par freem .
En réponse à la dépêche Haiku a 16 ans.
Évalué à 2.
Dernière modification le 30 août 2017 à 13:24.
Tu sais, je répondais à ça:
Par exemple comment obliger le thread à afficher une fenêtre vide dès qu'on lance l'application ?
D'ailleurs, maintenant que j'y pense, j'aurai peut-être pu mentionner windows et son fameux winmain (qui n'est pas utilisé pour ça, mais ça aurait pu).
J'aurai aussi du mentionner que la fonction main n'est pas la première chose à s'exécuter (init des variables globales, qui, en C++, peuvent inclure des singleton).
Enfin bref, quand on à le contrôle du chargeur de binaire, il sera difficile pour l'application de contourner les règles… encore faut-il qu'il y en ait ;) (pas trop le cas avec ELF sous linux contrairement à Haiku à priori, mais je ne maîtrise pas le sujet.)
Du coup, le temps nécessaire pour cela est reporté au moment où le décodage commence, et pas au chargement de l'application.
Mouai… ou pas, en fait. Ta lib à beau être déjà en mémoire, il faut quand même résoudre les symboles. La lecture d'un fichier sur disque dur, ce n'est pas ce qui coûte le plus cher au démarrage d'une application.
Ceci étant dit, ce phénomène peut être drastiquement réduit en limitant le nombre de symboles exportés par la lib, donc oui, je pense que si Haiku fait les choses bien, avec une API pas trop riche, il peut y avoir un vrai gain.
Du moins c'est le cas pour le format ELF.
Tu aurais au moins pu utiliser un pointeur intelligent franchement… même dans la vieille norme, il y avait auto_ptr (qui a ses défauts, ok, mais moins pire que le pointeur brut).
Sinon, j'ai une question: quid des applications qui ont besoin d'un rendu bien particulier? Typiquement les jeux, mais aussi blender, et de manière générale, tout ce qui fait appel à OpenGL?
Je sais que c'est un peu hors sujet, mais ça me semble un sujet important: le seul endroit ou il peut y avoir du feedback dans ces cas, c'est le curseur de souris ou les décorations de fenêtre…
Le protocole utilisé n'est pas documenté, et peut changer d'une version à l'autre de Haiku. Alors oui, en théorie c'est possible de réécrire tout le framework côté applicatif à partir de ça, mais franchement, pourquoi on ferait une chose pareille?
Mouai. Sauf qu'a ce moment, ils ont juste a aller voir mon FAI pour voir mes communications. Maintenant, personnellement je n'évite pas les GAFAM à cause du manque de respect de ma vie privée, mais bien du fait que dans pas mal de cas, y'a mieux ailleurs, le respect de la vie privée n'étant pas un bonus négligeable, certes (encore faudrait-il que je puisse prouver que les alternatives le sont, respectueuses… y'a un moment, faut faire confiance, pas le choix).
Plasma mobile aura de l’avenir quand il existera une distribution capable d’empaqueter et distribuer correctement les produits KDE. Pour le moment, même les développeurs KDE ont du mal.
Attends… comment ils font pour tester leurs logiciels s'ils n'arrivent même pas à les déployer de façon stable? Je savais que Debian avais des difficultés à gérer l'empaquetage, mais il me semblait que c'était à cause de la volonté de maintenir des paquets dans une version figée.
Du coup je suis surpris, une distrib par les dev de KDE pour KDE devrais avoir toujours les versions stables et être capables de migrer les config de la version n à la version n+1, non?
Bon sang, c'est toujours pénible de trouver un titre pour répondre dans le forum…
Plusieurs choses:
Tu as un guide pour formater tes messages en dessous du champ ou l'on écrit le message. Quand on débute sur linuxfr ça dépanne bien, d'expérience ;)
ça donne quoi avec rcp? Ça sera pas idéal, mais ça peut éventuellement te débloquer
je suis intrigué par le ssh qui traîne entre la source et la destination… et je ne vois rien dans la doc de rsync à ce sujet? Enfin, pas sans l'option --rsh=
Je te mets au défi de faire un audit sur le code source de toute ta pile réseau (du driver à firefox en passant par le kernel et les libs ssl).
Alors que d'un autre côté, certains (trop rares, ok) logiciels propriétaires ont, eux, des audits et certifications. Certes, on n'a pas accès au source, mais on sait qu'un tiers (et potentiellement un pro qui savait ce qu'il faisait, contrairement à moi qui ne me priverait pas pour autant de coder des soft réseau libre si j'ai l'occase, que tu finiras peut-être par utiliser, qui sait?) y a eu accès et à vérifié qu'il n'y a pas de grosses failles (il y en a toujours, mais déjà un audit réduit les risques, et je suppose que les plus grosses sont les moins complexes à repérer).
Libre != sécurisé, je pensais que heartbleed (entres autres) l'avait prouvé.
il faudrait aussi un système pour vérifier que le code compilé et installé dans le téléphone provienne bien des sources libres intactes
La compilation reproductible? J'en ai entendu parler vite fait, jamais creusé réellement… ça dois déjà pas être simple sur un système de bureau, alors sur un phone… meh!
En même temps, c'est ce qu'il demandait: comparer un système sur du matos ancien. C'est sûr, si tu mets du bloat, linux ou windows, ça va ralentir le système, surtout s'il est ancien et/ou restreint.
Toujours est-il que oui, on peut avoir un système (linux dans mon cas) réactif sur un truc qui devrait être relégué dans un musée. Pas avec n'importe quels logiciels, forcément. J'aurai pu utiliser LXDE aussi (déjà testé, ça passe bien) mais XFCE commence déjà à faire sentir le poids de ses outils. Des trucs qui fournissent plus de fonctionnalités, ça ne passe juste pas (animations, transparence réelle, calendrier intégré à tout, horloge "analogique" en couleur, seront autant de trucs qui risquent de ralentir, peut-être pas pris seuls, mais le combo est gagnant).
Si c'est ce genre d'info que tu veux, sache que je fais tourner linux sur un i586 (des softs compilés en 686 plantent à cause des instructions pas connues) cadencé à 700MHz et disposant de moins de 200Mio de RAM.
Ce n'est pas à proprement parler rapide (surtout quand je lance une compilation hihi), mais c'est réactif. Détail amusant: un soir ou je revenais de formation (avec donc le PC pro sur moi), je les ai fait faire la course.
Du bouton power au login réellement utilisable, les 2 systèmes vont aussi vite, windows, son octo-core et ses palanquées (16Gio) de RAM se font rattraper par le machin poussif designed for windows Me. La raison est simple: windows ne charge rien avant le login, tandis que le vieux BIOS mets 3 plombes.
Si je dois dire qui est responsable, je dirai que c'est mon choix d'outils: les logiciels que j'utilise, je les ai sélectionnés pour leur légèreté. i3, urxvt, zsh (important l'air de rien, il consomme moins de ram que bash tout en offrant un vrai confort supplémentaire), mpd, vim, xosview (parce que j'aime savoir si mon CPU passe plus de temps à attendre après le matos à vraiment bosser, et l'affichage des divers usages de la RAM m'est aussi utile pour savoir quand je dois laisser un peu d'air au système) et ce genre de jouets. J'arrive même à regarder des vidéos pas trop lourdes (mpv) et aller sur des sites pas trop lourds (uzbl, links2, netsurf, dillo).
La deuxième chose: sous Linux, chaque application utilise un ensemble de bibliothèques qu'il va falloir charger.
En effet. Sauf que… ce n'est pas si simple que ça. La grande majorité des distribs mettent toutes les libs en partagées, mais il existe des tentatives pour faire autrement. De la même manière, les distribs qui sont basées sur Debian vont hériter de la manie d'activer quasiment toutes les options: par exemple, mpd dépend de plusieurs lib dont le rôle, à vue de nez, est le même: support des wav. Il y a aussi une chiée de dépendance pour qu'il puisse lire les musiques utilisées par les jeux d'amiga ou atari, plusieurs qui semblent liées au format mp3, etc.
Bref, je ne crois pas que ce soit la faute de Linux, ni même des dev d'application. Enfin, peut-être un peu (c'est partagé en même temps) mais je pense que la majorité du problème viens des mainteneurs des distribs. Et, fatalement, des logiciels que l'on choisit d'utiliser. Celui qui mélange du KDE, du E17 du gnome et un peu de trucs avec motif, forcément qu'il va bloater son système.
Du coup, comme Haiku se positionne à la fois au niveau de l'OS, des applications et de la distrib, je comprend bien que ce soit plus simple de régler ce type de problème.
Hors, Linux n'a pas vraiment d'API graphique au sens affichage de boutons, de fenêtres, scrollbars, etc.
X11 en à peut-être, et je ne suis même pas sûr que ce soit vraiment le cas (motif peut-être? le truc super hideux la…): des gens ont construit Qt, Gtk, Fltk et sûrement bien d'autres, mais ce n'est aucunement lié à Linux. À X11, à la rigueur.
C'est la qu'un système comme Haiku peut, tant qu'on se limite aux outils «standards» qu'il fournit (j'imagine bien qu'on doit pouvoir contourner, ne serait-ce que parce que c'est du code libre), imposer la création de threads.
Nope, il ne l'était pas (modelio, c'est en java de mémoire). En même temps, il me faut l'admettre: à part AutoREALM, je ne connais aucun logiciel en pascal… ou aucun ne m'a marqué ^
Ou peut-être que l'on n'a pas la même définition de GAFAM.
Je n'ai besoin d'aucun de Google, d'Amazon, d'Apple, de Microsoft ni de Facebook pour recevoir et envoyer des mails, heureusement. Quant au web, ben, il faut dire que je ne cherche pas en permanence à découvrir de nouveaux site, du coup, entre ma mémoire, les signets et les onglets, je ne passe pas tant de temps que ça sur les moteurs de recherche, et je n'utilise de toute façon pas (directement) ceux des 5 entreprises citées.
Ah… d'accord. Mais du coup, c'est facile d'innover non? Il suffit de prendre les concurrents qui ne sont pas connus, de piquer les idées et de dire qu'on à inventé le concept?
En fait, le jour ou windows intègrera un (vrai) gestionnaire de fenêtre pavant, ce sera leur innovation? Puisqu'ils n'ont pas de concurrents directs…
Je me permets de ne pas être d'accord avec ta notion de concurrence directe, si on commence a virer les challengers parce qu'ils ne sont pas assez connus on va pas finir.
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 1.
Je pense que le fait qu'il n'y presque (il existe de rares forks de firefox) que la mofo qui utilise gecko joue aussi: moins de contributeurs. Reste maintenant à déterminer pourquoi tant d'autres projets préfèrent webkit à gecko…
Genre… la gestion de la mémoire, toutes les applications natives le font hein… avec plus ou moins de bonheur, certes.
A moins que, comme certains développeurs de jeux vidéo, FF ne fasse que de gros malloc et gère ensuite lui-même les blocs mémoire (surcharge de new et delete en C++, détournement de *alloc et free en C et C++ pour qu'ils pointent vers des fonctions custom)?
Je serai surpris (parce que l'augmentation de la consommation mémoire de FF me semble trop douce pour ce type de modèle, à moins que les chunks ne soient vraiment petits, mais je reconnais n'avoir pas creusé la question), mais pourquoi pas (et puis, vue la quantité de parsing qu'il doit gérer, ce ne serait pas débile).
C'est vrai, tous les navigateurs ne le font pas. J'en vois au moins… 1 seul en fait (uzbl, parce que le but est d'être minimaliste). Même dillo et netsurf le font (mais pas de JS, nous sommes d'accord).
Je doute qu'il implémente des pilotes graphiques. A mon avis, il fait comme tout le monde: il demande à l'os quelle version d'oGL est dispo, et ça ne prend pas tant de temps que ça (pas rapide d'initialiser un contexte opengl à première vue, ok, mais on est loin d'expliquer un temps de plusieurs secondes avec ça).
Le pire, c'est qu'au fond je suis d'accord avec toi: un browser, c'est complexe. Ceci dit, tu sembles chercher la petite bête pour défendre à tout prix firefox.
Personnellement, je me pose juste les questions suivantes: Haiku utilise une vieille version de webkit.
Quid du respect de la chiée de nouveaux standards de plus en plus complexes apparus depuis?
Quid des sandbox?
Firefox et les browsers multi-onglets que je connais tendent à avoir plusieurs processus et non threads pour sandboxer et éviter qu'un crash d'un onglet ne ferme le brouteur. Et celui de Haiku? Lancer un processus par page (si ce n'est plus), c'est autrement plus lourd que lancer 1 thread par page…
Bref, oui, il y a des raisons au "long" démarrage de firefox (j'ai vu pire perso), et il est probable que ça pourrait être amélioré (le code est pas tout neuf non plus, je ne serai pas surpris qu'il y ait plus que quelques dizaines de KLoc de dette technique, après tout l'origine date des années 90 hein) mais je m'interroge sur comment Haiku serait plus rapide en offrant la même sécurité et robustesse, en se basant sur du code obsolète…
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
Donc, il y a un contexte qui est initialisé quand on charge la lib, et qui référence les instances de fenêtres, les nettoyant quand elles se ferment? Admettons que ce soit une bonne idée (c'est la technique que semblait utiliser glfw2, abandonnée par la v3 étrangement quand ils semblent avoir ajouté le support de multi-fenêtrage. Bon, la sdl semble toujours faire ça, mais force m'est de reconnaître que les applications SDL ne s'interfacent pas super bien avec le reste de mon système), pourquoi dans ce cas utiliser des pointeurs nus et non des objets réels?
Ça éviterait que quelqu'un ne soit tenté de delete… d'ailleurs, si quelqu'un le faisait, il se passerait quoi?
# bugtracker, entres autres
Posté par freem . En réponse au message Logiciel suivi de problème / ticket system. Évalué à 2.
Le 1er terme par lequel j'ai appris à les appeler est bugtracker.
Et vu que tu connais bugzilla, tu aurais pu avoir l'info sur la page wikipedia qui lui est dédiée ;)
Pour le reste, personnellement j'aime bien redmine, mais je pense que c'est une question de goûts et d'habitude.
Accessoirement, redmine n'est pas un simple bugtracker mais une forge logicielle, donc offre potentiellement des fonctionnalités dont tu n'auras pas besoin (intégration d'outils de gestion de version (git, svn, cvs, bazaar, mercurial, etc), forum, wiki et j'en oublie).
En fait, ce sera difficile de te conseiller si tu ne nous dis pas pourquoi bugzilla ne te vas pas.
[^] # Re: Et pendant ce temps là...
Posté par freem . En réponse au journal Désactiver l'Intel ME: merci la NSA. Évalué à 3.
Pour ma défense (ou pas en fait), je ne suis pas remonté au post source :)
# grymoire
Posté par freem . En réponse au message Awk : Besoin d'explications. Évalué à 4.
Ce site est juste génial pour comprendre les outils UNIX quand on les découvre.
Je t'avoue ne pas maîtriser awk, mais je pense qu'en passant un peu de temps à lire la bonne section, tu devrais comprendre ce bout de code.
[^] # Re: Et pendant ce temps là...
Posté par freem . En réponse au journal Désactiver l'Intel ME: merci la NSA. Évalué à 5.
Ah ouai, culte ça:
Le mec il a une source récursive en fait :D attention au dépassement de pile hein, ça peut faire mal ces bêtes la…
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 2. Dernière modification le 30 août 2017 à 13:24.
Tu sais, je répondais à ça:
D'ailleurs, maintenant que j'y pense, j'aurai peut-être pu mentionner windows et son fameux winmain (qui n'est pas utilisé pour ça, mais ça aurait pu).
J'aurai aussi du mentionner que la fonction main n'est pas la première chose à s'exécuter (init des variables globales, qui, en C++, peuvent inclure des singleton).
Enfin bref, quand on à le contrôle du chargeur de binaire, il sera difficile pour l'application de contourner les règles… encore faut-il qu'il y en ait ;) (pas trop le cas avec ELF sous linux contrairement à Haiku à priori, mais je ne maîtrise pas le sujet.)
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Mouai… ou pas, en fait. Ta lib à beau être déjà en mémoire, il faut quand même résoudre les symboles. La lecture d'un fichier sur disque dur, ce n'est pas ce qui coûte le plus cher au démarrage d'une application.
Ceci étant dit, ce phénomène peut être drastiquement réduit en limitant le nombre de symboles exportés par la lib, donc oui, je pense que si Haiku fait les choses bien, avec une API pas trop riche, il peut y avoir un vrai gain.
Du moins c'est le cas pour le format ELF.
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
Tu aurais au moins pu utiliser un pointeur intelligent franchement… même dans la vieille norme, il y avait auto_ptr (qui a ses défauts, ok, mais moins pire que le pointeur brut).
Sinon, j'ai une question: quid des applications qui ont besoin d'un rendu bien particulier? Typiquement les jeux, mais aussi blender, et de manière générale, tout ce qui fait appel à OpenGL?
Je sais que c'est un peu hors sujet, mais ça me semble un sujet important: le seul endroit ou il peut y avoir du feedback dans ces cas, c'est le curseur de souris ou les décorations de fenêtre…
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
C'est bien ce que je voulais mettre en exergue :)
[^] # Re: Ceux qui ont choisis les deux premières questions...
Posté par freem . En réponse au sondage Ce que je suis prêt à laisser aux GAFAM. Évalué à 2.
Mouai. Sauf qu'a ce moment, ils ont juste a aller voir mon FAI pour voir mes communications. Maintenant, personnellement je n'évite pas les GAFAM à cause du manque de respect de ma vie privée, mais bien du fait que dans pas mal de cas, y'a mieux ailleurs, le respect de la vie privée n'étant pas un bonus négligeable, certes (encore faudrait-il que je puisse prouver que les alternatives le sont, respectueuses… y'a un moment, faut faire confiance, pas le choix).
[^] # Re: Matrix et Android
Posté par freem . En réponse au journal Un téléphone orienté sécurité et vie privée, avec du libre dedans. Évalué à 2.
Attends… comment ils font pour tester leurs logiciels s'ils n'arrivent même pas à les déployer de façon stable? Je savais que Debian avais des difficultés à gérer l'empaquetage, mais il me semblait que c'était à cause de la volonté de maintenir des paquets dans une version figée.
Du coup je suis surpris, une distrib par les dev de KDE pour KDE devrais avoir toujours les versions stables et être capables de migrer les config de la version n à la version n+1, non?
# re
Posté par freem . En réponse au message Connexion ssh - Permission denied (publickey,gssapi-keyex,gssapi-with-mic. Évalué à 2.
Bon sang, c'est toujours pénible de trouver un titre pour répondre dans le forum…
Plusieurs choses:
sshqui traîne entre la source et la destination… et je ne vois rien dans la doc de rsync à ce sujet? Enfin, pas sans l'option--rsh=[^] # Re: Les cookies
Posté par freem . En réponse au journal Firefox 57 - onglets contextuels et autres joyeusetés. Évalué à 3.
C'est ce que les défenseurs du tracking appellent de la publicité pertinente :)
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 1.
Je HAIS le code dupliqué!
[^] # Re: Matrix et Android
Posté par freem . En réponse au journal Un téléphone orienté sécurité et vie privée, avec du libre dedans. Évalué à 3. Dernière modification le 30 août 2017 à 08:47.
Je te mets au défi de faire un audit sur le code source de toute ta pile réseau (du driver à firefox en passant par le kernel et les libs ssl).
Alors que d'un autre côté, certains (trop rares, ok) logiciels propriétaires ont, eux, des audits et certifications. Certes, on n'a pas accès au source, mais on sait qu'un tiers (et potentiellement un pro qui savait ce qu'il faisait, contrairement à moi qui ne me priverait pas pour autant de coder des soft réseau libre si j'ai l'occase, que tu finiras peut-être par utiliser, qui sait?) y a eu accès et à vérifié qu'il n'y a pas de grosses failles (il y en a toujours, mais déjà un audit réduit les risques, et je suppose que les plus grosses sont les moins complexes à repérer).
Libre != sécurisé, je pensais que heartbleed (entres autres) l'avait prouvé.
La compilation reproductible? J'en ai entendu parler vite fait, jamais creusé réellement… ça dois déjà pas être simple sur un système de bureau, alors sur un phone… meh!
[^] # Re: La suggestion de recherche activée par défaut ça améliore la confidentialité ?
Posté par freem . En réponse à la dépêche Firefox 55 est prêt pour la rentrée 2017. Évalué à 2.
Tu aurais pu mettre en exergue le fait que savoir ce qu'est une URI est plus utile que savoir ce qu'est une URL :p
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
En même temps, c'est ce qu'il demandait: comparer un système sur du matos ancien. C'est sûr, si tu mets du bloat, linux ou windows, ça va ralentir le système, surtout s'il est ancien et/ou restreint.
Toujours est-il que oui, on peut avoir un système (linux dans mon cas) réactif sur un truc qui devrait être relégué dans un musée. Pas avec n'importe quels logiciels, forcément. J'aurai pu utiliser LXDE aussi (déjà testé, ça passe bien) mais XFCE commence déjà à faire sentir le poids de ses outils. Des trucs qui fournissent plus de fonctionnalités, ça ne passe juste pas (animations, transparence réelle, calendrier intégré à tout, horloge "analogique" en couleur, seront autant de trucs qui risquent de ralentir, peut-être pas pris seuls, mais le combo est gagnant).
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Si c'est ce genre d'info que tu veux, sache que je fais tourner linux sur un i586 (des softs compilés en 686 plantent à cause des instructions pas connues) cadencé à 700MHz et disposant de moins de 200Mio de RAM.
Ce n'est pas à proprement parler rapide (surtout quand je lance une compilation hihi), mais c'est réactif. Détail amusant: un soir ou je revenais de formation (avec donc le PC pro sur moi), je les ai fait faire la course.
Du bouton power au login réellement utilisable, les 2 systèmes vont aussi vite, windows, son octo-core et ses palanquées (16Gio) de RAM se font rattraper par le machin poussif designed for windows Me. La raison est simple: windows ne charge rien avant le login, tandis que le vieux BIOS mets 3 plombes.
Si je dois dire qui est responsable, je dirai que c'est mon choix d'outils: les logiciels que j'utilise, je les ai sélectionnés pour leur légèreté. i3, urxvt, zsh (important l'air de rien, il consomme moins de ram que bash tout en offrant un vrai confort supplémentaire), mpd, vim, xosview (parce que j'aime savoir si mon CPU passe plus de temps à attendre après le matos à vraiment bosser, et l'affichage des divers usages de la RAM m'est aussi utile pour savoir quand je dois laisser un peu d'air au système) et ce genre de jouets. J'arrive même à regarder des vidéos pas trop lourdes (mpv) et aller sur des sites pas trop lourds (uzbl, links2, netsurf, dillo).
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
En effet. Sauf que… ce n'est pas si simple que ça. La grande majorité des distribs mettent toutes les libs en partagées, mais il existe des tentatives pour faire autrement. De la même manière, les distribs qui sont basées sur Debian vont hériter de la manie d'activer quasiment toutes les options: par exemple, mpd dépend de plusieurs lib dont le rôle, à vue de nez, est le même: support des wav. Il y a aussi une chiée de dépendance pour qu'il puisse lire les musiques utilisées par les jeux d'amiga ou atari, plusieurs qui semblent liées au format mp3, etc.
Bref, je ne crois pas que ce soit la faute de Linux, ni même des dev d'application. Enfin, peut-être un peu (c'est partagé en même temps) mais je pense que la majorité du problème viens des mainteneurs des distribs. Et, fatalement, des logiciels que l'on choisit d'utiliser. Celui qui mélange du KDE, du E17 du gnome et un peu de trucs avec motif, forcément qu'il va bloater son système.
Du coup, comme Haiku se positionne à la fois au niveau de l'OS, des applications et de la distrib, je comprend bien que ce soit plus simple de régler ce type de problème.
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Ça s'appelle une API standard.
Hors, Linux n'a pas vraiment d'API graphique au sens affichage de boutons, de fenêtres, scrollbars, etc.
X11 en à peut-être, et je ne suis même pas sûr que ce soit vraiment le cas (motif peut-être? le truc super hideux la…): des gens ont construit Qt, Gtk, Fltk et sûrement bien d'autres, mais ce n'est aucunement lié à Linux. À X11, à la rigueur.
C'est la qu'un système comme Haiku peut, tant qu'on se limite aux outils «standards» qu'il fournit (j'imagine bien qu'on doit pouvoir contourner, ne serait-ce que parce que c'est du code libre), imposer la création de threads.
[^] # Re: Astérix
Posté par freem . En réponse à la dépêche diaspora* 0.7.0.0. Évalué à 3.
Bah… à force de voir des obélisques partout, fallait bien qu'astérisque se pointe…
Je suis déjà dehors
[^] # Re: Traduction ?
Posté par freem . En réponse au journal Le Développement Très Rapide d'Applications Libre. Évalué à 2.
Nope, il ne l'était pas (modelio, c'est en java de mémoire). En même temps, il me faut l'admettre: à part AutoREALM, je ne connais aucun logiciel en pascal… ou aucun ne m'a marqué ^
[^] # Re: Ceux qui ont choisis les deux premières questions...
Posté par freem . En réponse au sondage Ce que je suis prêt à laisser aux GAFAM. Évalué à 2.
Ou peut-être que l'on n'a pas la même définition de GAFAM.
Je n'ai besoin d'aucun de Google, d'Amazon, d'Apple, de Microsoft ni de Facebook pour recevoir et envoyer des mails, heureusement. Quant au web, ben, il faut dire que je ne cherche pas en permanence à découvrir de nouveaux site, du coup, entre ma mémoire, les signets et les onglets, je ne passe pas tant de temps que ça sur les moteurs de recherche, et je n'utilise de toute façon pas (directement) ceux des 5 entreprises citées.
[^] # Re: Programme Test Pilot
Posté par freem . En réponse au journal Firefox 57 - onglets contextuels et autres joyeusetés. Évalué à 5.
Ah… d'accord. Mais du coup, c'est facile d'innover non? Il suffit de prendre les concurrents qui ne sont pas connus, de piquer les idées et de dire qu'on à inventé le concept?
En fait, le jour ou windows intègrera un (vrai) gestionnaire de fenêtre pavant, ce sera leur innovation? Puisqu'ils n'ont pas de concurrents directs…
Je me permets de ne pas être d'accord avec ta notion de concurrence directe, si on commence a virer les challengers parce qu'ils ne sont pas assez connus on va pas finir.