jeberger a écrit 140 commentaires

Bin justement, là il n'y a pas de fichier de sous-titre. VLC analyse la piste son, la convertit en texte (éventuellement traduit), et affiche directement ce texte sans passer par un fichier.

Pour ce qui concerne les déficiences visuelles, VLC permet déjà de choisir la police, la taille et la couleur du texte, et d'ajouter un fond opaque. Ça ne permet-il pas de s'adapter à toutes les formes de déficience ? Et sans avoir besoin de prétraiter le fichier de sous-titres.

PS: Ceci-dit, avoir l'option d'enregistrer les sous-titres générés dans un fichier serait aussi une fonction intéressante…

Ha!

Sur la page Wikipedia en anglais:

For better or for worse, there is history, there is the book and then there's the movie. Timelines had to be conflated and [there were] composite characters, and for most people [who have seen the movie] have already taken that as the literal fact. … You might get the indication in the movie that these were the only people doing those jobs, when in reality we know they worked in teams, and those teams had other teams. There were sections, branches, divisions, and they all went up to a director. There were so many people required to make this happen. … It would be great for people to understand that there were so many more people. Even though Katherine Johnson, in this role, was a hero, there were so many others that were required to do other kinds of tests and checks to make [Glenn's] mission come to fruition. But I understand you can't make a movie with 300 characters. It is simply not possible.

Traduction libre:

Pour le meilleur ou pour le pire, il y a l'Histoire, il y a le livre, et puis il y a le film. Les événements ont dû être condensés et il y a eu des personnages composites, et pour la plupart, les gens [qui ont vu le film] le considèrent comme littéralement vrai. … Le film peut donner l'impression que ceux-ci étaient seuls à faire ces boulots, alors qu'en réalité nous savons qu'ils travaillaient en équipe, et que ces équipes avaient d'autres équipes. Il y avait des sections, des branches, des divisions, jusqu'à un directeur. Il y a eu besoin de tellement de monde pour réaliser cela. … Ce serait super si les gens comprenaient qu'il y avait autant de monde. Même si Katherine Johnson, dans ce rôle, était héroïque, il y en a eu tant d'autres qui ont été indispensables pour réaliser d'autres tests et vérification afin que la mission [de Glenn] soit un succès. Mais je comprends qu'on ne puisse pas réaliser un film avec 300 personnages. C'est juste impossible.

• choix des jeux d'icônes

→ ça ok ça n'existait pas dans les vieilles versions de MS Office

• choix du type d'interface (avec ou sans onglet, les rubans de MsOffice)

→ ça non plus ça n'existait pas avant le ruban (forcément)

• on peut personnaliser à fond les menus, les menus contextuels et les barres d'outils

→ ça en revanche ça existait, ça a disparu avec l'arrivée du ruban (il y a encore moyen de se faire une barre d'outils perso mais c'est archi limité)

• on peut créer des barres d'outils pour l'ensemble du logiciel, une application ou un document

→ idem, ça existait avant Office 2003 et le ruban

• on peut même remplacer les icônes (pas toutes) par les siennes

→ idem

• on peut changer de thème (pas assez à mon goût, mais bon)
• on peut personnaliser les couleurs de l'interface

→ idem. En fait c'était une fonctionnalité de Windows qui s'appliquait à toutes les applis utilisant les MFC (dont Office<2003)

• plus deux ou trois autres trucs.

Donc oui, l'apparence de Libre Office aujourd'hui, et particulièrement son apparence par défaut, correspond à ce que faisait MSOffice il y a 20 ans.

Évidemment ici "moderne" ne veut pas dire mieux et "vieux" ne veut pas dire obsolète, bien au contraire. La meilleure version de MSOffice était Office XP et il n'a pas arrêté de régresser depuis, alors que l'offre libre (OpenOffice puis LibreOffice) a énormément progressé dans le même temps et est aujourd'hui passée devant M$.

Bin c'est peu ou prou ce que faisait MsOffice avant d'introduire le ruban, donc oui c'est bien vieillot. C'est juste que contrairement à M$, LibreOffice à oublié de régresser ;)

C'est bien la défense de la langue française, mais quand on parle d'un auteur étranger c'est quand même bien de rappeler les titres originaux :

• Double étoile → Double Star
• Révolte sur la lune → The Moon is a harsh mistress
• Le chat passe-muraille → The cat who walks through walls

Marrant, je dirais le contraire: « podcaster » a la racine « cast » qui signifie « jeter » avec donc le sous-entendu que quelque chose est envoyé par le sujet, alors que « streamer » a pour racine « stream » qui signifie juste « flux » sans notion de direction…

Noter au passage que lsp/eglot sont juste une réimplémentation pour Emacs du "Language Server Protocol" introduit par Visual Studio Code. C'est-à-dire que le service qui tourne en tâche de fond est le même pour lsp/eglot et VSCode.

Source: Wikipedia

Je n'ai jamais su ce qu'il cherchait à faire, non.

Dans ma boîte, un jour quelqu'un a lancé un chmod -x /usr/bin/* /usr/sbin/* sur tous les PC Linux de tous les utilisateurs via le logiciel de gestion de parc…

Thunderbird savait, mais la fonctionnalité a été retirée après la version 78: https://bugzilla.mozilla.org/show_bug.cgi?id=1727931

Il y a 3 mois, ils parlaient de le remettre mais pour l'instant ce n'est pas fait…

Euh, non c'est toujours là…

« ce n'est pas l'acceptation courante » → « ce n'est pas l'acception courante » (Larousse)

Mais via les cycles de référence il est tout à fait possible d'avoir des fuites de mémoires ; et donc un GC optionnel aurait du sens en effet.

Rust ne permet pas de faire des cycles de références (hors code unsafe), sauf à utiliser des pointeurs faibles (Weak), il n'est donc pas possible d'avoir des fuites de mémoire (du moins pas plus qu'avec un ramasse-miettes).

Je connaissais avant, je ne sais plus où j'en avait entendu parler (probablement Diaspora). Mais plus on parle de Mercurial et de ce qui va autour plus je suis content ☺

Oui, je cherche clairement une solution alternative d'ici juin, et je regarde Heptapod de très près. Et si je peux éviter d'administrer moi-même le truc ça m'arrangerait bien…

Ironique quand on connaît la lenteur des sites de Google…

complémentation → complétion ou achèvement (aucun des deux ne correspond exactement à l'anglais « completion, » mais « complémentation » est encore plus éloigné).

Juste une petite remarque: il n'y a que deux « S » à « SSE3 »

Je conseille de rajouter cela dans votre ~./.bashrc:

Plutôt dans le ~/.profile qui a l'avantage de fonctionner même pour ceux qui n'utilisent pas bash, voire dans le ~/.xprofile qui vaut aussi pour l'environnement graphique (mais qui peut dépendre des distrib)…

En fait l'article décrit trois attaques :

• La première touche absolument tous les processeurs modernes quel que soit le fabriquant (y compris probablement les OpenMIPS et OpenSPARC bien qu'ils ne soient pas cités) et permet à un processus d'accéder à sa propre mémoire. Alors pourquoi est-ce un problème (et pourquoi le processus ferait-il comme ça plutôt que d'accéder directement à la mémoire) ? Tout simplement parce qu'un script tournant sur une VM (de type VM javascript) peut exploiter la faille pour lire n'importe où dans la mémoire du processus (donc par exemple dans la mémoire concernant les autres onglets du navigateur). Noter à ce sujet que le noyau Linux contient une VM (eBPF) utilisée à l'origine pour les pare-feux et qui permet à n'importe quel programme d'exécuter un script en espace noyau et donc de lire toute la mémoire du noyau (à un rythme de 1500 octets/s environ). Cette attaque devrait pouvoir être patchée au niveau logiciel dans les VM avec un coût relativement faible.

• La deuxième attaque n'a été démontrée que sur les processeurs Intel, mais ARM reconnaît que ses processeurs sont aussi vulnérables. AMD prétend que les siens ne sont pas touchés (plus exactement AMD dit que personne n'a montré que cette faille touche leurs processeurs, mais rien ne prouve qu'ils sont immunisés). Cette faille demande une connaissance très poussée de l'unité de prédiction de branchement du CPU (que les auteurs ont obtenue par rétro-ingénierie sur les processeurs Intel) ainsi que du code de l'OS ou de l'hyperviseur cible. L'attaque permet d'injecter du code dans le contexte de l'OS ou de l'hyperviseur. Elle fonctionne en trompant l'unité de prédiction de branchement pour que celle-ci fasse exécuter du code choisi par l'attaquant au moment où l'OS cible fait un branchement conditionnel. Le résultat de ce code sera jeté quand le CPU s’apercevra de l'erreur de prédiction, mais des effets secondaires peuvent rester visibles (en particulier le chargement de données en cache). Je n'ai pas entendu parler de correctif pour cette attaque…

• La troisième attaque ne concernerait que les processeurs Intel et vient du fait que la MMU contrôle l'accès a posteriori. Elle permet à un processus de lire une page mémoire qui est présente dans son espace d'adressage, même si la lecture de cette page est normalement interdite. Elle ne permet pas en revanche de lire une page mémoire non présente dans l'espace d'adressage. La raison pour laquelle cette attaque pose problème c'est qu'une grande partie de la mémoire des OS est présente dans l'espace d'adressage des applications en mode lecture interdite (en tout cas pour Linux et Windows) afin d'accélérer les appels systèmes (il est beaucoup plus rapide de changer les permissions d'une page existante que d'ajouter ou de supprimer des pages dans la MMU). Les patchs du noyau Linux dont on parle visent à retirer la mémoire de l'OS de l'espace d'adressage des applications, ce qui bloquera cette attaque mais augmente considérablement le coût des appels système (jusqu'à 60% de perte de performance sur des benchmarks synthétiques, PostgresSQL a été mesuré à -17% quand ces patchs sont activés).

Utilisateur Mercurial depuis toujours, je ne me suis pas incliné à git :)

Pareil, au pire j'utilise hggit pour interagir avec les moutons qui utilisent Git (qui a dit "broken by design"?)

Je suis le seul a être gêné par les % 0xFFFF ? Ça ne devrait pas plutôt être & 0xFFFF ou % 0x10000 ?

Yaurait pas comme l'ébauche d'un problème là ? Mon Pi 1 tourne à 700 BogoMIPS (697.95 pour être précis). Je doute que le 3 soit à ce point moins bon…

Et aussi : « déformation due à une mauvaise pause » → « déformation due à une mauvaise pose »