Ce n'est pas très clair dans cet article, mais ce changement consiste pour l'instant à ajouter Skia en parallèle de Cairo mais aussi des autres moteurs disponibles: la version de WebKit utilisée par Safari n'utilise pas Cairo et n'utilisera probablement pas non plus Skia.
Du côté de Haiku, sans accélération OpenGL, il est peut-être peu intéressant pour nous d'utiliser Skia? Pour l'instant, haikuwebkit utilise les APIs de BeOS et le rendu graphique est fait par l'app_server de Haiku.
La situation avant le "schisme" de Blink mentionné dans l'article était similaire: Skia était utilisé uniquement par Google pour Chrome, et les autres versions de WebKit utilisaient d'autres bibliothèques. C'est ce qui explique pourquoi le support de Skia avait été retiré de la base de code de WebKit à l'époque.
Surtout qu'on pourrait utiliser une traduction plus appropriée de "fork", comme par exemple "bifurquer" ou "embrancher". Ou alors un mot utilisé dans d'autres contextes pour plus ou moins la même idée, comme "essaimer", "fissionner", "scissionner"… Les choix ne manquent pourtant pas, c'est dommage d'utiliser un mot qui finalement n'est qu'un anglicisme masqué par une mauvaise (volontairement ou pas) traduction littérale?
Et de manière pas tout à fait négligeable, il y a une série de journaux qui auraient toute leur place comme dépêche mais certaines personnes idéalisent à mon sens un peu trop ce que doit être une dépêche.
Les dépêches mettent beaucoup moins en avant l'auteurice (son avatar n'est pas affiché par exemple), et le passage en modération (ou les interventions d'autres contributeurs dans l'espace de rédaction) aboutissent parfois à des modifications relativement importantes.
Le résultat est que les dépêches doivent d'une certaine façon, mieux suivre la ligne éditoriale du site et s'en tenir aux standards existants.
De plus, l'existence d'un espace de rédaction qui permet de stocker un travail en cours, encourage à utiliser cette fonctionnalité, et donc à travailler sur des contenus longs, en y passant plus de temps. Pour les journaux il n'y a rien de tel, ça doit donc être rédigé en cuelques minutes et en une seule fois.
Les journaux permettent un style et des sujets plus personnels. Rien qu'en voyant l'avatar en haut, on sait un peu à quoi s'attendre.
En résumé (le "c'est trop long j'ai pas lu" comme on dit): l'interface utilisateur influe sur l'usage qui est fait du site, et inversement.
Globalement, le système fonctionne bien, la plupart des dépèches finissent quand même par être publiées, même si certaines prennent pas mal de temps.
Certaines sont menées par une seule personne ou un petit groupe. Mais même dans ce cas là, les "petites" contributions et relectures sont bonnes à prendre pour améliorer le contenu avant qu'il arrive entre les mains de la modération (j'espère que vous ne m'en voulez pas trop pour mes textes de 10 kilomètres sur Haiku ou les évolutions du langage C).
Il y a quand même des choses qui ont pas trop mal fonctionné. Récemment j'ai en tête les bonnes résolutions de début d'année, et avant ça, une lecture collective d'un livre sur C++ qui je pense a été enrichissante pour les participants à la rédaction, peut-être plus que pour les lecteurs? Effectivement dans ces cas là, il y a une personne qui a pris les choses en main.
D'autres cas où ça se passe moins bien: les dépêches entamées suite au décès d'une personalité de l'informatique: la meilleure solution serait de préparer ce genre de dépêche à propos de personne encore vivantes. Mais je trouve ça intéressant d'avoir des portraits un peu élaborés et un retour en détail sur l'oeuvre accomplie. C'est incompatible avec la publication dans l'actualitédes évènements.
Enfin je pense à une autre dépêche qui a eu une gestaion difficile, celle sur la voiture qui n'aimait pas la glace à la vanille. Elle a empilé deux problèmes: un abandon par l'initiateur de la dépêche, et l'objectif initial était de faire une traduction d'un texte existant, mais le texte initial s'est avéré mal sourcé et peu fiable. Malgré tout, je crois que le résultat était intéressant.
Il reste le problème des textes abandonnés en cours de route, et de ceux où quelqu'un (je crois que c'st souvent la même personne) dépose trois liens en vrac puis disparaît sans laisser de traces. OsDans ces cas là, je pense effectivement qu'il vaut mieux, soit publier en l'état, soit supprimer le truc si personne ne s'empare du sujet. La prochaine fois, postez un lien ou un journal pour lancer les débats, ce sera plus intéressant.
Voilà, c'était mun retour personnel pour les dépêches auxquelles j'ai plus ou moins participé.
Il semble qu'on peut toujours utiliser Bird.Makeup pour suivre Twitter depuis le Fediverse (bon il faut donc avoir un moyen de consulter du ActivityPub, mais ça peut se faire sans compte je pense?):
Oui, bien sûr, la raison pour utiliser Windows est que j'ai besoin de plein d'autres outils, dont certains non libres.
Par exemple:
atfblast, pour programmer des composants PAL/GAL (ATF22v10 et ATF16v8) dans mon cas (libre mais pas maintenu, disponible uniquement pour Windows, la version qui fonctionne pour Windows 7 est déjà patchée par rapport à l'original qui ne fonctionne que sous Windows 98 et les versions antérieures). Un jour j'en ferai une version pour Haiku, le code est disponible et ça ne devrait pas être trop compliqué à adapter.
L'IDE et la toolchain SunPlus unSP pour compiler des choses pour la console VTech V.Smile (basé sur uen vieille version de GCC, donc en théorie ça devrait être libre, mais SunPlus ne diffuse pas les sources. Je suis en train de porter VBCC pour remplacer tout ça de toutes façons).
Parfois des outils pour débloquer/rooter des téléphones (ça dépend du modèle de téléphone, dans certains cas ça se fait mieux avec des outils pour Linux, parfois pas).
Ça c'est pour mes projets du moment, il y en a quelques autres dans le même style. Et donc je n'ai pas envie d'ajouter encore un système Linux supplémentaire car c'est déjà assez compliqué comme ça avec 2 machines. Ce qui fait que, beaucoup de choses que je pourrais faire sous Linux (mais pas sous Haiku) se retrouvent sur cette même machine avec Windows pour l'instant. Ça m'oblige à utiliser Haiku pour le maximum de choses, avec Linux ça ne marcherait pas aussi bien car il est pas aussi compliqué que ça :)
Le français est un langage compliqué et plein de dette technique, surtout à l'écrit. Il y a des gens pour qui c'est "naturel" ou "logique" et d'autres pas du tout. Ça n'empêche pas d'avoir des compétences dans plein d'autres domaines.
On peut discuter de la pertinence des outils choisis pour améliorer les choses, mais ça ne me semble pas très constructif d'être condescendant comme ça?
J'ai peut-être déjà vu un système de ce type sur un site francophone partageant des informations sur les logiciels libres qui porte le nom d'un noyau de système d'exploitation très connu, mais j'ai oublié de quel site il s'agit.
--depth permet de ne pas récupérer l'historique. Svn permet en plus de ne pas récupérer tous les dossiers du dépôt mais seulement une sous-arborsescence. Ce qui pourrait régler tous les débats sur les "monorepos contre submodules" dans git et les outils comme google repo pourgérer ces problématiques
J'ai vu des entreprises ou svn était utilisé pour gérer une base de documents (pas du code). En gros ça permettait de facilement synchroniser un dossier avec tous les documents sur son PC pour l'avoir sous la main, et de signaler (mais pas de résoudre) les conflits d'édition.
C'était utilisé par des gens pas forcément très techniques, via une interface graphique (tortoisesvn par exemple).
Au delà des fonctions manquantes dans git (par exemple: la possibilité de "verrouiller" un fichier pendant qu'on l'édite), le problème avec git serait surtout qu'il est trop compliqué: branches locales et distantes et plein d'autres concepts, qui en plas ne sont pas forcément bien exposés dans les interfaces graphiques. Ça ne marcherait donc pas du tout aussi bien dans cet usage.
ça fera probablement plus de boulot en modération, notamment pour déplacer des journaux et des liens vers la rubrique HS. Mais vu que cette rubrique sera un fourre-tout, donc un appeau à trolls, nul doute qu'il y aura beaucoup de dérapages, dont certains relevant du pénal
faut des volontaires pour mettre la main à la pâte. Tout dépend du niveau de complexité de la modification, du nombre de doigts et du temps de cerveaux disponibles pour taper du code
Maissoyons sérieux, personne ne vient sur Linuxfr en se disant "tiens, et si j'allais chercher des liens qui ne parlent surtout pas de Linux et encore moins de logiciels libres?"
Non, ce qu'il faudrait c'est un moyen de masquer les contenus pas intéressants, parce cu'ils sont hors sujet, ou de mauvaise qualité (c'est à dire, par exemple, tellement mal rédigés qu'on y comprend rien). On pourrait mettre en place quelque chose pour indiquer si un contenu est pertinent, et qu'on veut en lire plus, ou inutile, et on voudrait que l'auteur perde son temps d'une autre façon. Et on pourrait faire confiance à l'intelligence gollective des visiteurs du site pour utiliser ce système à bon escient et ainsi avoir une sorte de ligne éditoriale qui émerge par elle-même et qui peut évoluer au cours du temps, le tout, sans donner de travail supplémentaire à l'équipe de modération.
Je suis sûr que cette idée va déclencher beaucoup de débats, mais il faudrait au moins essayer pour voir ce qui en ressort?
Que la plupart des gens n'ont pas vu la différence une fois mis devant le fait accompli
C'est probablement ça, la plupart des gens ne font pas trop la différence entre "internet", "web", "navigateur" et "moteur de recherche". Donc, un navigateur qui s'installe tout seul, il va rester chez eux sans problème.
Mozilla avait réussi à contrer ça avec de l'innovation (pas des trucs forcément très compliqués, par exemple, des onglets, un système de restauration de session, …) qui apportaient une grosse plus-value par rapport à la concurrence. Actuellement ce n'est plus trop le cas. Mais ça peut rechanger si Chrome se met trop sérieusement à empêcher les bloqueurs de publicités, par exemple.
au final il y a eu plus de gain que de perte au niveau des employés.
Au niveau financier, peut-être, mais démarrer un nouveau job dans l'informatique ça demande un investissement mental qui n'est pas remboursable. Et perdre ce job vec un préavis court àun moment ou plusieurs milliers d'autres personnes sont en même temps remise sur le marché du travail, c'est pas beaucoup mieux.
Je trouve ça pas plus mal que le commentaire de la personne ayant posté le lien soit séparé du lien lui-même. On peut en conséquence commenter et pertinenter/inutiler l'un indépendament de l'autre.
On peut aussi ne pas lire les commentaires quand on a pas le temps.
Ça habitue/encourage aussi les gens à mettre des étiquettes plutôt qu'un commentaire et on a donc une belle base de liens organisés parcatégories et qu'on peut retrouver si besoin sans trop de mal. C'est malheureusement beaucoup moins le cas pour les autres contenus. Vu l'état actuel des moteurs de recherche dont on dépend beaucoup (résultats pleins de pages inutiles générées par des LLMs), c'est peut-être dommage que les autres contenus ne soient pas aussi bien rangés.
Le noyau linux n'a globalement qu'une seule implémentation.
Les noyaux compatibles UNIX il y en a plusieurs douzaines.
Pareil pour les langages de programmation, la plupart de ceux qui sont un peu sérieux ont au moins 2 implémentations.
De plus pour ce qui est de la vie privé par exemple, je présume que peu de chose sont dans le moteur lui-même et donc qu'Opera est moins problématique que Chrome.
Je ne sais pas, mais je sais par contre que Google trouve normal d'avoir ajouté de la télémétrie dans le compilateur Go, qui envoie donc des infos sur le code qu'on essaie de compiler à Google. Je doute que leur moteur soit conçu en pensant en priorité à la protection de la vie privée des utilisateurs.
Les trois navigateurs nommés sur celle de 2022 sont – quoique pas tout à fait pour Safari – Chrome avec une moustache
Pardon? Le fork de Blink/Chrome à partir de WebKit c'était il y a 10 ans. En 10 ans il se passe plus de truc que se laisser pousser la moustache.
Côté Blink, on a un projet qui refuse de merger les patchs pour tout autre système que Linux, Windows, Android et Mac OS (sauf si Google change d'avis). Je pense que c'est pareil pour les architectures matérielles.
Côté WebKit, on a un projet qui maintient des builds 32 bit, du MIPS, prend en charge les systèmes BSD, et est aussi porté sur Haiku et MorphOS et utilisé également dans des systèmes embarqués.
Le moteur Javascript n'est pas du tout le même (c'était déjà le cas avant le fork de Blink: il y avait 2 moteurs maintenus en parallèle dans le même dépôt Git). La pile de rendu n'est plus du tout la même non plus (WebKit peut fonctionner sans OpenGL, impossible pour Blink). La couche réseau n'est pas la même (Apple utilise ses propres APIs, WebKit sous Linux c'est soit Soup soit Curl, Blink c'est les trucs de Google).
Comparaison au Starlite Mk II d'après les fiches techniques:
On gagne des ports USB en plus (du A et du C, y'en a pour tout le monde), un port HDMI normal au lieu du micro-HDMI, et un port Ethernet. L'autonomie est annoncée à 12h contre 7.
On "perd" (il est plus gros) 1.9mm d'épaisseur, 5mm de profondeur, et 24mm de largeur. Il faut bien rentrer l'écran 13" quelque part.
Il pèse 885 grammes dans sa config la plus légère ce qui fait tout de même une réduction de 20% par rapport aux 1.1kg du Starlite, tout en conservant un chassis en métal (c'est du magnésium au lieu de l'aluminium).
En bonus, il est aussi disponible en 2 couleurs: noir ou rouge.
Il m'arrive de lire Linuxfr depuis un téléphone. Ça ne m'empêche pas de prendre un ordinateur avec un vrai clavier quand j'ai besoin ou envie d'écrire quelque chose de long.
Donc, il faudrait plutôt regarder la proportion d'utilisateurices qui ne se connectent jamais depuis une machine avec un clavier, pour voir si ça a vraiment un impact sur les contenus longs, ou si c'est juste qu'on a aujourd'hui le luxe de pouvoir utiliser des terminaux différents pour la production et la consommation des informations.
Pour l'un des touts premiers logiciels que j'ai écrits (pour réviser mes tables de multiplications), je ne connaissais pas les boucles et je n'avais pas compris que l'ordinateur pouvait calculer le résultat des multiplications à ma place pour vérifier les résultats. J'avais donc programmé à la main, une par une, toutes les questions (de type "3 x 6 = ?") et toutes les réponses, avant d'apprendre à faire tout ça.
Ce logiciel a ensuite été entièrement réécrit 2 fois, pour migrer de QBASIC à RapidQ (un langage similaire à QBASIC mais qui permettait d'avoir une interface graphique sous Windows) puis en Delphi. J'ai arrêté son développement après avoir installé Linux sur mon PC, n'ayant pas réussi à faire fonctionner mon projet avec Kylix et n'ayant pas eu le courage de le réécrire une nouvelle fois en C++ et WxWidgets (j'avais commencé mais ce n'est jamais allé très loin).
Il y a quelques calculs complexes. Plus on descend, plus on consomme d'air (ou autre mélange) des bouteilles à chaque respiration, parce que la pression augmente et donc la quantité d'air dans les poumons, à volume égal, augmente aussi.
Ce qui fait que ce n'est pas simple de savoir où on en est de sa réserve d'air et à quelle vitesse elle va se vider, en tenant compte aussi du temps pour remonter incluant les paliers de décompression.
Ça rend assez intéressante l'utilisation d'un ordinateur pour calculer tout ça en temps réel.
Et, en cas d'accident, si jamais il y en a un, ça sert de "boîte noire" pour savoir ce qu'il s'est passé.
# Précision
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comme tous les autres moteurs de rendu, WebKit (ré)adopte la bibliothèque graphique Skia. Évalué à 4.
Ce n'est pas très clair dans cet article, mais ce changement consiste pour l'instant à ajouter Skia en parallèle de Cairo mais aussi des autres moteurs disponibles: la version de WebKit utilisée par Safari n'utilise pas Cairo et n'utilisera probablement pas non plus Skia.
Du côté de Haiku, sans accélération OpenGL, il est peut-être peu intéressant pour nous d'utiliser Skia? Pour l'instant, haikuwebkit utilise les APIs de BeOS et le rendu graphique est fait par l'app_server de Haiku.
La situation avant le "schisme" de Blink mentionné dans l'article était similaire: Skia était utilisé uniquement par Google pour Chrome, et les autres versions de WebKit utilisaient d'autres bibliothèques. C'est ce qui explique pourquoi le support de Skia avait été retiré de la base de code de WebKit à l'époque.
[^] # Re: le titre m'a trompé !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche L’auteur de Nginx enfourche le proprio. Évalué à 6.
Je crois que "schismer" n'existe pas encore, mais ça peut s'envisager.
Il y a aussi "mitose" si on va chercher du côté de la biologie, mais lui non plus n'a pas de forme verbale à ma connaissance?
[^] # Re: le titre m'a trompé !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche L’auteur de Nginx enfourche le proprio. Évalué à 10.
Surtout qu'on pourrait utiliser une traduction plus appropriée de "fork", comme par exemple "bifurquer" ou "embrancher". Ou alors un mot utilisé dans d'autres contextes pour plus ou moins la même idée, comme "essaimer", "fissionner", "scissionner"… Les choix ne manquent pourtant pas, c'est dommage d'utiliser un mot qui finalement n'est qu'un anglicisme masqué par une mauvaise (volontairement ou pas) traduction littérale?
[^] # Re: Yacy
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Stract, un moteur de recherche libre codé par un Danois sur son temps libre. Évalué à 3.
Je rajoute Marginalia à la liste des moteurs de recherche dont le code est libre (AGPL): https://search.marginalia.nu
[^] # Re: Mes 22 centimes...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l’espace de rédaction Linuxfr. Évalué à 7.
Les dépêches mettent beaucoup moins en avant l'auteurice (son avatar n'est pas affiché par exemple), et le passage en modération (ou les interventions d'autres contributeurs dans l'espace de rédaction) aboutissent parfois à des modifications relativement importantes.
Le résultat est que les dépêches doivent d'une certaine façon, mieux suivre la ligne éditoriale du site et s'en tenir aux standards existants.
De plus, l'existence d'un espace de rédaction qui permet de stocker un travail en cours, encourage à utiliser cette fonctionnalité, et donc à travailler sur des contenus longs, en y passant plus de temps. Pour les journaux il n'y a rien de tel, ça doit donc être rédigé en cuelques minutes et en une seule fois.
Les journaux permettent un style et des sujets plus personnels. Rien qu'en voyant l'avatar en haut, on sait un peu à quoi s'attendre.
En résumé (le "c'est trop long j'ai pas lu" comme on dit): l'interface utilisateur influe sur l'usage qui est fait du site, et inversement.
# Parlons des dépêches qui fonctionnent
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l’espace de rédaction Linuxfr. Évalué à 10.
Globalement, le système fonctionne bien, la plupart des dépèches finissent quand même par être publiées, même si certaines prennent pas mal de temps.
Certaines sont menées par une seule personne ou un petit groupe. Mais même dans ce cas là, les "petites" contributions et relectures sont bonnes à prendre pour améliorer le contenu avant qu'il arrive entre les mains de la modération (j'espère que vous ne m'en voulez pas trop pour mes textes de 10 kilomètres sur Haiku ou les évolutions du langage C).
Il y a quand même des choses qui ont pas trop mal fonctionné. Récemment j'ai en tête les bonnes résolutions de début d'année, et avant ça, une lecture collective d'un livre sur C++ qui je pense a été enrichissante pour les participants à la rédaction, peut-être plus que pour les lecteurs? Effectivement dans ces cas là, il y a une personne qui a pris les choses en main.
D'autres cas où ça se passe moins bien: les dépêches entamées suite au décès d'une personalité de l'informatique: la meilleure solution serait de préparer ce genre de dépêche à propos de personne encore vivantes. Mais je trouve ça intéressant d'avoir des portraits un peu élaborés et un retour en détail sur l'oeuvre accomplie. C'est incompatible avec la publication dans l'actualitédes évènements.
Enfin je pense à une autre dépêche qui a eu une gestaion difficile, celle sur la voiture qui n'aimait pas la glace à la vanille. Elle a empilé deux problèmes: un abandon par l'initiateur de la dépêche, et l'objectif initial était de faire une traduction d'un texte existant, mais le texte initial s'est avéré mal sourcé et peu fiable. Malgré tout, je crois que le résultat était intéressant.
Il reste le problème des textes abandonnés en cours de route, et de ceux où quelqu'un (je crois que c'st souvent la même personne) dépose trois liens en vrac puis disparaît sans laisser de traces. OsDans ces cas là, je pense effectivement qu'il vaut mieux, soit publier en l'état, soit supprimer le truc si personne ne s'empare du sujet. La prochaine fois, postez un lien ou un journal pour lancer les débats, ce sera plus intéressant.
Voilà, c'était mun retour personnel pour les dépêches auxquelles j'ai plus ou moins participé.
[^] # Re: Terrible Maps
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Making a PDF that’s larger than Germany. Évalué à 2.
Il semble qu'on peut toujours utiliser Bird.Makeup pour suivre Twitter depuis le Fediverse (bon il faut donc avoir un moyen de consulter du ActivityPub, mais ça peut se faire sans compte je pense?):
https://bird.makeup/@TerribleMaps
# Problème connu depuis longtemps
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comment compromettre Bitlocker sur TPM en 43 secondes avec un Raspberry Pi à moins de 10$ 😇. Évalué à 9.
Une page détaillée expliquant le fonctionnement de cette attaque, qui date de 2021:
https://blog.scrt.ch/2021/11/15/tpm-sniffing/
Mais bon, c'est un blog avec des photos et plein de détails, pas une vidéo youtube, alors c'est moins impressionnant, je suppose?
[^] # Re: Windows 7 vs Linux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faire fonctionner sous Windows 7 les applications utilisant Python 3.9. Évalué à 2.
La dernière chose dont j'ai envie, c'est de me retrouver à corriger des bugs dans un deuxième OS libre en plus de Haiku.
[^] # Re: Windows 7 vs Linux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faire fonctionner sous Windows 7 les applications utilisant Python 3.9. Évalué à 3.
Il y a qemu mais sans accélération. Et puis, lancer Windows en natif ou en virtualisé, ça ne change pas grand chose à mon problème.
On devrait pouvoir sans trop de difficulté porter nvmm depuis netbsd. Il faut "juste" que quelqu'un prenne le temps de s'y mettre.
[^] # Re: Windows 7 vs Linux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faire fonctionner sous Windows 7 les applications utilisant Python 3.9. Évalué à 6.
Oui, bien sûr, la raison pour utiliser Windows est que j'ai besoin de plein d'autres outils, dont certains non libres.
Par exemple:
Ça c'est pour mes projets du moment, il y en a quelques autres dans le même style. Et donc je n'ai pas envie d'ajouter encore un système Linux supplémentaire car c'est déjà assez compliqué comme ça avec 2 machines. Ce qui fait que, beaucoup de choses que je pourrais faire sous Linux (mais pas sous Haiku) se retrouvent sur cette même machine avec Windows pour l'instant. Ça m'oblige à utiliser Haiku pour le maximum de choses, avec Linux ça ne marcherait pas aussi bien car il est pas aussi compliqué que ça :)
[^] # Re: les ia ont massacré une partie de mon journal
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Panne de l'ordinateur interne d'un Surface Allen & Heath I-live T112. Évalué à 7.
Le français est un langage compliqué et plein de dette technique, surtout à l'écrit. Il y a des gens pour qui c'est "naturel" ou "logique" et d'autres pas du tout. Ça n'empêche pas d'avoir des compétences dans plein d'autres domaines.
On peut discuter de la pertinence des outils choisis pour améliorer les choses, mais ça ne me semble pas très constructif d'être condescendant comme ça?
[^] # Re: Pourquoi pas une rubrique HS ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Quel futur vous paraît pertinent pour la rubrique « Liens » de Linuxfr ? . Évalué à 3.
J'ai peut-être déjà vu un système de ce type sur un site francophone partageant des informations sur les logiciels libres qui porte le nom d'un noyau de système d'exploitation très connu, mais j'ai oublié de quel site il s'agit.
[^] # Re: Futur de Subversion
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal github et subversion c'est fini (ou de l'importance d'une bonne communication). Évalué à 5.
--depth permet de ne pas récupérer l'historique. Svn permet en plus de ne pas récupérer tous les dossiers du dépôt mais seulement une sous-arborsescence. Ce qui pourrait régler tous les débats sur les "monorepos contre submodules" dans git et les outils comme google repo pourgérer ces problématiques
[^] # Re: Futur de Subversion
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal github et subversion c'est fini (ou de l'importance d'une bonne communication). Évalué à 6.
J'ai vu des entreprises ou svn était utilisé pour gérer une base de documents (pas du code). En gros ça permettait de facilement synchroniser un dossier avec tous les documents sur son PC pour l'avoir sous la main, et de signaler (mais pas de résoudre) les conflits d'édition.
C'était utilisé par des gens pas forcément très techniques, via une interface graphique (tortoisesvn par exemple).
Au delà des fonctions manquantes dans git (par exemple: la possibilité de "verrouiller" un fichier pendant qu'on l'édite), le problème avec git serait surtout qu'il est trop compliqué: branches locales et distantes et plein d'autres concepts, qui en plas ne sont pas forcément bien exposés dans les interfaces graphiques. Ça ne marcherait donc pas du tout aussi bien dans cet usage.
[^] # Re: Pourquoi pas une rubrique HS ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Quel futur vous paraît pertinent pour la rubrique « Liens » de Linuxfr ? . Évalué à 6.
Maissoyons sérieux, personne ne vient sur Linuxfr en se disant "tiens, et si j'allais chercher des liens qui ne parlent surtout pas de Linux et encore moins de logiciels libres?"
Non, ce qu'il faudrait c'est un moyen de masquer les contenus pas intéressants, parce cu'ils sont hors sujet, ou de mauvaise qualité (c'est à dire, par exemple, tellement mal rédigés qu'on y comprend rien). On pourrait mettre en place quelque chose pour indiquer si un contenu est pertinent, et qu'on veut en lire plus, ou inutile, et on voudrait que l'auteur perde son temps d'une autre façon. Et on pourrait faire confiance à l'intelligence gollective des visiteurs du site pour utiliser ce système à bon escient et ainsi avoir une sorte de ligne éditoriale qui émerge par elle-même et qui peut évoluer au cours du temps, le tout, sans donner de travail supplémentaire à l'équipe de modération.
Je suis sûr que cette idée va déclencher beaucoup de débats, mais il faudrait au moins essayer pour voir ce qui en ressort?
[^] # Re: Edge vs Chrome
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Terrible Maps : The most popular browser 2012 vs 2022. Évalué à 5.
C'est probablement ça, la plupart des gens ne font pas trop la différence entre "internet", "web", "navigateur" et "moteur de recherche". Donc, un navigateur qui s'installe tout seul, il va rester chez eux sans problème.
Mozilla avait réussi à contrer ça avec de l'innovation (pas des trucs forcément très compliqués, par exemple, des onglets, un système de restauration de session, …) qui apportaient une grosse plus-value par rapport à la concurrence. Actuellement ce n'est plus trop le cas. Mais ça peut rechanger si Chrome se met trop sérieusement à empêcher les bloqueurs de publicités, par exemple.
[^] # Re: L'informatique c'est vaste
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal [Trolldi] La Big Tech vous souhaite une très belle réflexion existentielle. Évalué à 9.
Au niveau financier, peut-être, mais démarrer un nouveau job dans l'informatique ça demande un investissement mental qui n'est pas remboursable. Et perdre ce job vec un préavis court àun moment ou plusieurs milliers d'autres personnes sont en même temps remise sur le marché du travail, c'est pas beaucoup mieux.
[^] # Re: garder la rubrique, imposer une petite description
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Quel futur vous paraît pertinent pour la rubrique « Liens » de Linuxfr ? . Évalué à 8.
Je trouve ça pas plus mal que le commentaire de la personne ayant posté le lien soit séparé du lien lui-même. On peut en conséquence commenter et pertinenter/inutiler l'un indépendament de l'autre.
On peut aussi ne pas lire les commentaires quand on a pas le temps.
Ça habitue/encourage aussi les gens à mettre des étiquettes plutôt qu'un commentaire et on a donc une belle base de liens organisés parcatégories et qu'on peut retrouver si besoin sans trop de mal. C'est malheureusement beaucoup moins le cas pour les autres contenus. Vu l'état actuel des moteurs de recherche dont on dépend beaucoup (résultats pleins de pages inutiles générées par des LLMs), c'est peut-être dommage que les autres contenus ne soient pas aussi bien rangés.
[^] # Re: Le monopole du moteur
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Terrible Maps : The most popular browser 2012 vs 2022. Évalué à 10.
Les noyaux compatibles UNIX il y en a plusieurs douzaines.
Pareil pour les langages de programmation, la plupart de ceux qui sont un peu sérieux ont au moins 2 implémentations.
Je ne sais pas, mais je sais par contre que Google trouve normal d'avoir ajouté de la télémétrie dans le compilateur Go, qui envoie donc des infos sur le code qu'on essaie de compiler à Google. Je doute que leur moteur soit conçu en pensant en priorité à la protection de la vie privée des utilisateurs.
[^] # Re: Le monopole du moteur
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Terrible Maps : The most popular browser 2012 vs 2022. Évalué à 10.
Pardon? Le fork de Blink/Chrome à partir de WebKit c'était il y a 10 ans. En 10 ans il se passe plus de truc que se laisser pousser la moustache.
Côté Blink, on a un projet qui refuse de merger les patchs pour tout autre système que Linux, Windows, Android et Mac OS (sauf si Google change d'avis). Je pense que c'est pareil pour les architectures matérielles.
Côté WebKit, on a un projet qui maintient des builds 32 bit, du MIPS, prend en charge les systèmes BSD, et est aussi porté sur Haiku et MorphOS et utilisé également dans des systèmes embarqués.
Le moteur Javascript n'est pas du tout le même (c'était déjà le cas avant le fork de Blink: il y avait 2 moteurs maintenus en parallèle dans le même dépôt Git). La pile de rendu n'est plus du tout la même non plus (WebKit peut fonctionner sans OpenGL, impossible pour Blink). La couche réseau n'est pas la même (Apple utilise ses propres APIs, WebKit sous Linux c'est soit Soup soit Curl, Blink c'est les trucs de Google).
# Plus léger
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la disparition du format « pas trop grand ». Évalué à 5.
Chez Fujitsu il y a un peu plus grand, mais plus léger:
https://www.fujitsu.com/global/products/computing/pc/notebooks/lifebook-u9312/
Comparaison au Starlite Mk II d'après les fiches techniques:
On gagne des ports USB en plus (du A et du C, y'en a pour tout le monde), un port HDMI normal au lieu du micro-HDMI, et un port Ethernet. L'autonomie est annoncée à 12h contre 7.
On "perd" (il est plus gros) 1.9mm d'épaisseur, 5mm de profondeur, et 24mm de largeur. Il faut bien rentrer l'écran 13" quelque part.
Il pèse 885 grammes dans sa config la plus légère ce qui fait tout de même une réduction de 20% par rapport aux 1.1kg du Starlite, tout en conservant un chassis en métal (c'est du magnésium au lieu de l'aluminium).
En bonus, il est aussi disponible en 2 couleurs: noir ou rouge.
[^] # Re: étiquettes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Statistiques 2023 du site LinuxFr.org. Évalué à 4.
Il m'arrive de lire Linuxfr depuis un téléphone. Ça ne m'empêche pas de prendre un ordinateur avec un vrai clavier quand j'ai besoin ou envie d'écrire quelque chose de long.
Donc, il faudrait plutôt regarder la proportion d'utilisateurices qui ne se connectent jamais depuis une machine avec un clavier, pour voir si ça a vraiment un impact sur les contenus longs, ou si c'est juste qu'on a aujourd'hui le luxe de pouvoir utiliser des terminaux différents pour la production et la consommation des informations.
# ça peut arriver à tout le monde
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien la manière la plus efficace de déterminer si un nombre est pair. Évalué à 9.
Pour l'un des touts premiers logiciels que j'ai écrits (pour réviser mes tables de multiplications), je ne connaissais pas les boucles et je n'avais pas compris que l'ordinateur pouvait calculer le résultat des multiplications à ma place pour vérifier les résultats. J'avais donc programmé à la main, une par une, toutes les questions (de type "3 x 6 = ?") et toutes les réponses, avant d'apprendre à faire tout ça.
Ce logiciel a ensuite été entièrement réécrit 2 fois, pour migrer de QBASIC à RapidQ (un langage similaire à QBASIC mais qui permettait d'avoir une interface graphique sous Windows) puis en Delphi. J'ai arrêté son développement après avoir installé Linux sur mon PC, n'ayant pas réussi à faire fonctionner mon projet avec Kylix et n'ayant pas eu le courage de le réécrire une nouvelle fois en C++ et WxWidgets (j'avais commencé mais ce n'est jamais allé très loin).
Il faut bien commencer quelque part :)
[^] # Re: Tout se paye un jour ou l'autre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 5.
Il y a quelques calculs complexes. Plus on descend, plus on consomme d'air (ou autre mélange) des bouteilles à chaque respiration, parce que la pression augmente et donc la quantité d'air dans les poumons, à volume égal, augmente aussi.
Ce qui fait que ce n'est pas simple de savoir où on en est de sa réserve d'air et à quelle vitesse elle va se vider, en tenant compte aussi du temps pour remonter incluant les paliers de décompression.
Ça rend assez intéressante l'utilisation d'un ordinateur pour calculer tout ça en temps réel.
Et, en cas d'accident, si jamais il y en a un, ça sert de "boîte noire" pour savoir ce qu'il s'est passé.