pulkomandy a écrit 1730 commentaires

De toutes façons, pot catalytique ou pas, 10km tu les feras plus vite et en polluant moins avec un vélo.

Tu as oublié des éruptions solaires record aussi. La fin du monde est proche!

Si tu débauches quelqu'un qui a déjà un emploi dans une autre entreprise, tant que les entretiens ne sont pas terminés, c'est réversible. Une fois que la période d'essai a commencé, il a déjà quitté son ancien travail et ça peut devenir plus compliqué pour lui.

Ils n'hésitent pas à recontacter les gens et leur proposer de passer les entretiens une deuxième fois. Si je comprend bien, c'est aussi une façon de voir si les gens sont assez motivés pour repasser toutes les étapes une deuxième fois (en connaissant les "bonnes" réponses par coeur, donc).

J'ai déjà passé un entretien sous forme de QCM (questions vrai/faux, pour être précis), mais ça s'est fait à l'oral et en direct. Du coup, il y a des possibilités de "contester" les bonnes réponses et de trouver d'éventuels bugs dans le code proposé (ça tournait autour des pièges du C).

Et maintenant que je suis dans l'entreprise en question, je confirme que c'est bien nécessaire pour le travail qu'il y a à faire.

Je confirme, j'ai passé à peu près le même genre d'entretien téléphonique pour entrer chez Google (mais pas en temps que "director of engineering"). Il s'agit d'un premier entretien où les questions sont posées par un responsable du recrutement qui vérifie juste les réponses sans comprendre ce qu'on lui dit. Ce n'est donc pas un test technique, mais un test de culture générale sur l'informatique.

Une fois cette première phase passée, il y a une série d'entretien techniques, d'abord par téléphone + google docs, et ensuite sur place avec un tableau blanc. La procédure s'est arrêtée là pour moi. Mon ressenti est que j'ai trouvé ce format de recrutement trop orienté sur la technique. C'est certes important, mais il ne faudrait pas oublier de tester un peu les gens sur leur personnalité et regarder leur parcours aussi. Sinon ça devient assez inhumain, et je ne suis pas qu'une machine à écrire du code, merci.

J'ajouterai aussi que le processus de recrutement chez Google est très bien documenté et sans surprise. Pour les gens qui ont pris le temps de se renseigner avant de postuler, il est donc facile d'avoir les bonnes réponses sous les yeux pour passer cette première étape. Ce qui vous donne droit au badge "social engineering". Peut être que c'est ça le but, en fait?

100° c'est la température d'évaporation pas de fusion, je crois :)

Il y a des emplacements vélos dans la plupart des trains intercités ainsi que dans les TER (mais là ça dépend des régions, je suppose?). La capacité d'accueil est dimensionnée en fonction de l'utilisation que les gens en font, parfois il y a just 4 ou 5 emplacements pour tout un train, parfois il y a un demi wagon réservé à ça (mais souvent encombré de bagages).

En tout cas, j'ai toujours pu trouver une place pour mon vélo lorsque c'était nécessaire. Même parfois alors que ce n'était pas indiqué lors de l'achat du billet de train, d'ailleurs.

C'est qui qui parlait de ne pas généraliser, quelques commentaires plus tôt?

Moi je suis exclusivement cycliste (pas de permis de conduire), j'ai plusieurs collègues qui viennent travailler en vélo, et on n'a en général que rarement à se plaindre des automobilistes.

Pour autant je n'en fait pas une généralité, et je ne pense pas pouvoir dire que je fais partie du "milieu des cyclistes" (pas plus que du "milieu des libristes", d'ailleurs, malgré des heures passées à développer du code libre, je ne me reconnaît pas du tout dans l'image classique du libriste barbu).

un peu comme pour la GPL où c'est la GPL-2.0 qui inclut par défaut le GPL-2 + (sauf quand il est expressément retiré comme pour le noyau Linux…)

Pas exactement. La GPL 2.0 elle-même ne dit rien là-dessus. Cependant, le texte que la FSF propose d'utiliser pour choisir la GPL indique "version 2 ou n'importe quelle version ultérieure". Précisément cela apparaît dans "How to Apply These Terms to Your New Programs", juste après la fin de la license (END OF TERMS AND CONDITIONS) ici: https://www.gnu.org/licenses/old-licenses/gpl-2.0.fr.html

Dans le texte de la licence il est bien précisé que ce changement de version n'est possible que si c'est spécifié explicitement de cette façon.

Je n'ai pas trop à me plaindre des voitures non plus, et pas du tout des camions (qui doublent toujours uniquement là ou c'est possible et en laissant plein de place). Pourtant je travaille au milieu d'un centre logistique,donc des camions, y'en a plein (mais je roule peu en centre ville).

Le passage le plus dangereux sur mon trajet, c'est une voie partagée piétons/cyclistes ou je dois éviter les chiens qui courent se jeter sous mes roues…

Où peut-être une intersection route/tram mal pensée. en vélo, traverser un rail de tramway perpendiculairement ne pose pas trop problème. Traverser à un angle de 30° ou moins deviens dangereux, surtout si on a des pneus pas trop larges qui risquent de s'insérer dans la rainure du rail.

ça va un peu dans le sens de ce que je dis: en conduisant une automobile moderne, avec airbag, carrosserie amortissante, ceintures, et qui roule à 130km/h sans vibrer de partout, tu vas avoir tendance à faire moins attention à ta sécurité.

Globalement, les mesures de sécurité sont quand même suffisamment efficace pour que ça soit un progrès (mais y'a pas que ça pour expliquer la baisse du nombre de morts sur les routes, les infrastructures ont aussi beaucoup évolué, il y a les radars automatiques, etc).

si tu sors du choc frontal/latéral de base ton auto 5 étoiles euro NCAP peut dans certains cas être aussi peu sûre qu'une vieille fiat panda des années 80.

Plus dangereuse, car elle roule plus vite et comme elle ne vibre pas de partout comme si elle allait se disloquer, tu fais moins attention.

Donc selon toi, la ceinture de sécurité ne devrait pas être obligatoire car on part du principe que les gens sont tous assez intelligents, matures et responsables pour se gérer eux même ?

C'est pas ça: le casque devrait être obligatoire aussi pour les piétons et les automobilistes. Y'a pas de raison, ils prennent autant voir plus de risques que les cyclistes.

Chaque fenêtre est associée à un thread. Du coup, on ne peut pas faire facilement fonctionner un appel au destructeur "normal", il faut que la destruction se fasse forcément depuis le thread propre à la fenêtre.

Pour la détruire, on lui envoie un message (B_QUIT_REQUESTED, en l'occurence) qui sera traité par sa boucle d'évènements. La fenêtre peut d'ailleurs refuser de se fermer (par exemple si elle contient un document non enregistré et qu'elle veut d'abord demander à l'utilisateur s'il est d'accord pour perdre ses changements).

Le traitement du message se termine par la libération de la mémoire occupée par la fenêtre, puis l'arrêt de l'exécution du thread.

Si on fait un delete sans arrêter la boucle d'évènements, l'application va probablement se planter dès que la fenêtre en question va recevoir un évènement. Cependant, il y a quelques sécurités pour avoir un genre de weak reference vers une fenêtre pour lui envoyer des messages seulement si elle existe encore. Dans ce cas, le thread continuera d'exister mais ne recevra plus de messages. Pour éviter cela, l'appel du destructeur de la fenêtre ouvre directement le debuger avec un message d'erreur clair pour le développeur ("you can't call delete on a BLooper object once it is running"). Et donc, normalement ce genre de code ne devrait pas survivre très longtemps.

Version obsolète, c'est un peu exagéré. On utilise actuellement un WebKit de mars 2016. Alors certes, ce n'est pas la toute dernière version, mais c'est quand même pas si ancien que ça.

Pour les sandboxes, ce n'est pas encore fait (c'est ce qu'apporte webkit2 - le moteur de rendu étant le même entre webkit1 et webkit2). ça viendra un jour mais c'est un assez gros travail de passer de webkit1 à webkit2 et on a pas encore eu le temps de s'y mettre. De plus, cela devient plus facile avec les versions plus récentes de WebKit qui commencent à mieux séparer les parties spécifiques à chaque plateforme du code commun à toutes. Donc on préfère d'abord rattraper un peu notre retard sur les versions à jour du moteur, avant de se pencher sur ce problème.

Cependant, si on faisait un processus par page, on pourrait afficher la fenêtre principale encore plus vite, et lancer ces processus seulement lorsque les onglets sont affichés pour la première fois. Du coup, l'apparition de la fenêtre serait encore plus rapide, mais par contre l'apparition de la page dans la fenêtre, serait elle un peu plus lente (encore que, lancer un process, c'est pas forcément un truc qui prend des heures non plus).

De mon point de vue, ça semble bien: je clique sur l'icône du navigateur, et paf, la fenêtre apparaît. Ensuite, la page se charge, mais j'ai une barre de progression en bas de l'écran qui m'indique qu'une opération potentiellement lente est en cours (téléchargement depuis le réseau, lancement du process de rendu, et tout le bazar). C'est ce genre de chose qui me semble importantes pour une interaction confortable avec un ordinateur. Que les traitements soit longs, ça ne me pose pas de problème, par contre, les actions de l'utilisateur doivent être prises en compte immédiatement et avec un retour rapide à l'écran, pour qu'on sache que l'ordre est reçu.

Un splash screen est l'exemple le moins discret. En réfléchissant un peu on peut faire quelque chose de plus subtil et qui passe inaperçu. Exemple amusant: sur iOS, les applications sont packagées avec une capture d'écran de la première chose qu'elles affichent. Cette image est affichée tout de suite quand on lance l'application. Du coup, on a l'impression que le système réagit très vite, et éventuellement que c'est l'application qui met du temps à s'activer. Mais on a au moins un retour sur le fait que l'application est lancée.

Qu'est-ce qui est arrivé à Firefox pour qu'il soie si lourd? Haiku a un navigateur web basé sur WebKit, certes pas parfait, mais qui permet quand même d'afficher un grand nombre de pages web sans trop de problèmes. Je ne dirais pas que WebKit est une bibliothèque légère, mais ce n'est que quelques méga-octets de code à charger. Et comme les autres applications, le navigateur affiche une fenêtre et est prêt à fonctionner en moins d'une seconde.

Pourtant, je pense que c'est l'une des applications qui fait le plus "mal" les choses. En effet, l'architecture de WebKit (et surtout de WebKit 1 qui est encore utilisé dans Haiku) se prête très mal au fonctionnement avec plusieurs threads. En conséquence, une grande partie du rendu graphique est faite dans le thread de l'application et pas dans celui de la fenêtre. Mais ça, ça ne ralentit pas le temps de démarrage.

Alors certes, on ne fait pas tout ce que fait Firefox, mais quand même, je pense que pour démarrer le navigateur et afficher une fenêtre, il ne devrait pas y avoir tant de choses à faire que ça? Ce n'est que plus tard, quand on commence à navigure sur des pages compliquées pleines de Javascript et d'effets graphiques animés, qu'on devrait commencer à avoir des problèmes.

Pourquoi donc Firefox met-il tant de temps à se charger et à ouvrir une fenêtre?

Tu remarqueras l'absence de delete dans ce code. C'est volontaire: ces deux classent se suppriment toute seules, respectivement lorsque la fenêtre est fermée, et lorsque l'application est quittée. L'utilisation d'un smart pointer est donc inutile ici.

Pour OpenGL, on commence par créer une BWindow comme ci-dessus, puis on lui ajoute une BGlView qui permet d'obtenir un contexte OpenGL. On peut également utiliser EGL, qui se chargera alors de créer la fenêtre.

Le serveur graphique lui-même va créer un thread de son côté pour gérer les interactions avec l'application. Donc ça fait au moins un thread.

De l'autre côté, si on veut attaquer les choses en bas niveau, on a un protocole à base de communication inter-process avec des "ports", qui permettent d'envoyer et de recevoir des messages. 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?

    int main(void)
    {
        BApplication* app = new BApplication("x-vnd/PulkoMandy-test");
        BWindow* window = new BWindow(BRect(100, 100, 400, 400), "Une fenêtre!", B_DOCUMENT_WINDOW_LOOK, B_QUIT_ON_WINDOW_CLOSE);
        window->Show();
        app->Run();
        return 0;
    }

Voilà à quoi va ressembler le main() de la plupart des applications pour Haiku. En 4 lignes de code, on a donc:
- Créé et affiché une fenêtre (ce qui lance un thread pour traiter les évènements de cette fenêtre: redimensionnement, fermeture, etc),
- Créé une boucle d'évènement pour l'application (BApplication) qui tourne dans le thread principal (Run() ne rend pas la main tant que l'application n'est pas quittée).

Il peut y avoir quelques variantes, du genre, créer la fenêtre plutôt dans le constructeur de l'application ou au pire dans son callback ReadyToRun(). Mais dans les trois cas ce sera très tôt au lancement de l'application, et je ne vois pas pourquoi il faudrait plusieurs secondes pour instancier 2 objets C++ (même compliqués).

Parlons décodage de médias alors:

Une application native pour Haiku utilisera pour cela le "Media Kit" (dans la bibliothèque libmedia.so). Au chargement de l'application, il y a juste besoin de charger cette lib, qui est de toutes façons déjà en mémoire puisque par exemple, elle est utilisée par l'icône "systray" pour le contrôle du volume.

Le chargement des codecs spécifiques ne se fera qu'à la demande lorsque l'application voudra décoder (ou encoder) un fichier média. Du coup, le temps nécessaire pour cela est reporté au moment où le décodage commence, et pas au chargement de l'application.

Dans Haiku, tu ne peux pas créer une fenêtre sans créer un thread qui va gérer sa boucle d'évènement. A ma connaissance, sur tous les autres systèmes, si tu veux faire une fenêtre avec son propre thread pour gérer les évènements, c'est possible, mais il faut créer le thread explicitement. Du coup, sous Haiku, pour faire une application qui n'arrive pas à afficher rapidement sa fenêtre, il faut le faire exprès.

La deuxième chose: sous Linux, chaque application utilise un ensemble de bibliothèques qu'il va falloir charger. Sous Haiku, le système de base fournit déjà pas mal de fonctionnalités dans deux ou trois bibliothèques partagées, qui du coup sont tout le temps chargées en RAM puisque tout le monde les utilise. Du coup, il y a beaucoup moins besoin d'accès disques pour charger toutes les dépendances de chaque application. D'où, je suppose, un lancement plus rapide.

Tu as déjà du retard, le futur c'est le "personal cloud":

http://www.seagate.com/fr/fr/consumer/backup/personal-cloud/

J'en avais déjà parlé dans les commentaires de la dépêche de l'an dernier, SamWang a mis un lien vers mes réponses de l'époque dans un de ses commentaires.

Ce n'est pas évident de corréler mon ressenti avec des explications concrètes sur ce qu'il se passe vraiment (surtout sur les systèmes Linux et Windows, que je connaît moins bien).

Dans les faits, si on fait un benchmark, on verra que dans la plupart des cas, Haiku met plus de temps à faire les choses. Cela s'explique par plusieurs raisons, dont les plus évidentes:
- L'utilisation de gcc2 là où un compilateur plus récent optimiserait mieux (sauf sur la version 64bits de Haiku, qui utilise un compilateur à jour),
- Le fait que l'on privilégie la lisibilité et la clarté du code, sans forcément pousser très loin la recherche de performance (on a pas les mêmes besoins qu'un Linux qui doit gérer des serveurs avec plusieurs milliers d'utilisateurs connectés, et on a pas assez de développeurs pour faire ce genre de choses non plus)
- Le fait que les versions actuellement diffusées de Haiku ont un noyau en mode "paranoïaque", c'est à dire qu'il effectue des opérations coûteuses pour simplifier le débugage (par exemple, effacer la mémoire avant de la libérer pour avoir plus de chances de détecter un accès après libération).

Mais malgré tout, à l'utilisation, Haiku réagit toujours immédiatement quand on clique sur un bouton, et ce même sur les machines les plus modestes (on a encore quelques utilisateurs avec des CPUs dépassant péniblement les 400MHz).

La raison tient principalement à la conception de l'API de Haiku, dans laquelle chaque fenêtre affichée à l'écran possède deux threads dédiés (un dans l'application, un dans le serveur graphique) et indépendants du thread principal de l'application. Avec ce modèle, une fenêtre n'est jamais bloquée en attente d'un quelconque évènement, et elle réagit toujours quand on la manipule. Même si c'est pour afficher une barre de progression et dire que le traitement en cours va prendre un moment.

Aussi bien sous Linux que sous Windows, j'ai en permanence un indicateur de la charge CPU et de l'activité du disque dur. C'est souvent le seul moyen que j'ai de savoir que l'ordinateur est en train de réfléchir, après avoir appuyé sur un bouton. À force d'utiliser Haiku, j'ai peu de tolérance aux applications qui mettent plus d'une seconde à se lancer, par exemple.

J'ai pourtant essayé d'alléger mon Linux autant que possible. J'utilise IceWM, un environnement de bureau très peu gourmand avec aucun service en arrière plan. Cependant j'ai toujours l'impression de devoir attendre que l'ordinateur réagisse dès que je fais quelque chose.

Voilà, je n'ai qu'un ressenti et quelques pistes pour tenter de l'expliquer. Et je préfère investir mon temps à rendre Haiku encore plus rapide qu'à essayer de comprendre pourquoi les autres sont à la traîne.