Christophe a écrit 673 commentaires

En même temps, c'est également assez marrant de voir un support de seulement 1 an pour une version LTS…

C'est un projet très intéressant, merci pour la découverte !

Ceci dit quand je lis sur la doc d'installation:

If missing, Java 17, Node.js and npm will be installed automatically using the system's package manager.

je me pose des questions sur la légèreté du bousin… Quelqu'un a essayé par ici ?

Ah, j'avais raté cette exception. Bon ben ça tue toute l'initiative, tout le monde va s'appuyer dessus.

Mais du coup pourquoi redévelopper de zéro, si Trilium remplit tous les critères ? Il y a même la prise de notes avec plugin MCP: https://docs.triliumnotes.org/user-guide/llm

Personnellement je pense surtout à Trilium. C'est un projet très actif, aux nombreuses fonctionnalités, architecture client-serveur optionnelle, synchronisation des notes, j'en suis pleinement satisfait.

… et honte à GrapheneOS de communiquer de la sorte.

Cet élitisme toxique donne juste envie de fuir ce projet, qui par ailleurs semble très bien sur le point de vue technique.

Pareil, je suis parti sur un auto-hébergement (pour les maigres besoins de la famille), et j'ai complété par un encouragement financier.

Ça marche plutôt bien, et si petit souci il y a c'est assez flexible au niveau des règles de récupération d'articles.

Tout d'abord bravo pour ce financement, cela permettra à ChienGPT de fournir une expérience encore plus réaliste. Cet ajout permettra aussi de faire un bond dans les performances.

Une question cependant: est-ce qu'on sait quelles ont été les conditions d'entrainement de ces puces spécialisées ? Ont-elles eu droit à un corpus dédié ? N'y a-t-il un risque qu'elles aient été contaminées ?

Arf, zut, bien vu :)

A mon avis, ils pourront argumenter tout leur possible, je ne vois pas le tribunal juger cette restriction comme "raisonnable", vu qu'elle empêche complètement le but premier de la licence AGPL.

OpenOffice est en train de se tirer une balle dans le pied: ils viennent de clamer que leur produit n'est ni libre, ni indépendant. Leur stratégie je pense est que l'action en justice va prendre du temps, et que les institutions vont hésiter à partir sur un solution incertaine juridiquement. Et que d'ici la perte du procès, Euro-Office sera mort-né.

Les agents d'IA peuvent faire des commits très bien organisés, ce n'est plus vraiment le problème.

C'est effectivement très vaste… Mais il y a quand même de grandes catégories:

• une aide ponctuelle pour des petites morceaux de code ou du refactoring. En gros, l'IA fait une tâche ingrate à ta place, et il y a juste à vérifier qu'elle n'a pas loupé le changement 57 sur les 109 repérés…
• une aide à l'analyse: l'IA regarde le code, dit ce qui semble être incorrect, et le développeur le prend en compte pour la suite
• une quasi-autonomie: on demande à l'IA de coder un truc (un nouveau pilote, une optimisation…) et le LLM va pondre un truc, plus ou moins impactant et volumineux. Un gros travail de relecture est alors nécessaire.

Pour moi c'est le cas n°3 qui est problématique: certes le code va être relu, mais va-t-il être compris ? Les subtilités introduites par l'IA (en s'inspirant d'un autre code pas forcément adapté) vont-elle être repérées et intégrées ?
Il y a un réel risque de perte de contrôle sur le code produit, dans le sens où plus personne ne saura ce que le code fait, ou pourquoi il le fait ainsi. Pour un projet très technique comme systemd, c'est un risque que je trouve inquiétant.

Je ne vois pas trop comment c'est possible en dehors du « do-not-track » des navigateurs web. Pourrais-tu préciser ?

Tout simplement avec… un cookie. Ce type de cookie est accepté dans le cadre du RGPD, car il est essentiel au fonctionnement du site web.

Personnellement, ce que je souhaite, c'est que les sites web voulant respecter le RGPD soient obligés de stocker mes préférences même si je refuse tout cookie de traçage. Et bien sûr, obligés de le prendre en compte ensuite.

C'est tout à fait faisable aujourd'hui dans le cadre du RGPD, mais beaucoup de sites font semblant de ne pas le savoir afin de reproposer leurs traçage publicitaire à chaque visite, dans l'espoir qu'on finisse par craquer.

Merci pour ces mesures très intéressantes !

En effet, un RPi est tellement lent que malgré sa faible consommation en charge, il va être moins "efficace" qu'un mini-pc.

Cependant, en introduction, la question était: "Pour un petit serveur personnel alimenté H24 à la maison, je choisis quoi". Et là, je pense qu'il reste une question ouverte: quelle sera la charge du petit serveur, en moyenne, sur l'année ?

J'ai moi-meêm un Rpi4 à la maison, sur lequel je fais tourner quelques services. Avec un ou deux utilisateurs, la charge système dépasse très rarement 0.5. On est donc en Idle, très, très souvent.

Si on fait un rapide calcul, en reprenant tes chiffres de consommation idle/charge, on peut déterminer à partir de quelle temps de charge sur l'année le mini-pc devient plus intéressant… Mais il y a un piège: vu que le N150 est bien plus puissant, il sera aussi moins longtemps en charge !
Donc à tâches égales, si le RPi4 prend 9071s, alors le N150 ne sera en charge que 530s, soit un facteur 17.

Prenons mon Rpi4 en exemple, avec le N150 en concurrent:

Rpi4: W.h = 6*t_charge + 3*(t_total-t_charge) = 3*t_total + 3*t_charge
N150: W.h = 22*(t_charge/17) + 5*(t_total-(t_charge/17)) = 5*t_total + 17*t_charge/17

On remarque une coïncidence: pour que la consommation totale du Rpi4 soit moins intéressante que celle du N150, il faut qu'il soit en charge… tout le temps !

J'ai probablement fait une (ou plusieurs) erreur grossière de méthodo, n'hésitez pas à m'en informer ^{^}

Et surtout, simuler une catastrophe serveur, et tester que la restauration à partir d'un des backups marche réellement !

freenews.fr ? Ce serait étonnant, même si ce n'est pas impossible.

Je ne vois aucunement le rapport avec le libre.

Ça ressemble surtout à une copie illégale de masse, sous couvert de vouloir faire de la préservation d'oeuvres.

Si on se fie à cet article, il semble que « raclonette » soit principalement un mot marketing, et ait quasiment disparu avec l'arrêt de la commercialisation de l'appareil en question:

Pendant deux décennies, toutes les mentions du mot raclonette que l’on trouve dans la presse sont présentes dans des encarts publicitaires des appareils de la marque SIGG.

Personnellement, je découvre ce mot aujourd'hui, je ne l'avais jamais entendu avant.

Je ne fais pas partie des 0.019% de ces utilisateurs, mais de toutes façons j'utilise XFCE, qui le propose (apparemment c'est du code inspiré de fvwm2 et de twm).

Et puis, à en lire les premiers commentaires du bug, la fonctionnalité existait "presque" en 2005 avec Kde 3: le seul problème était qu'il fallait sélectionner manuellement les fenêtres à sauvegarder/restaurer. Ce patch là, oui, j'aurais pu l'écrire.

Si on suit les commentaires des devs kwin dans le rapport de bug, on lit deux choses:
- c'est très demandé (« Based on the list of duplicates and votes, It's clear that this is a very highly desired feature by our users »)
- ils considèrent que ce n'est pas faisable par le compositeur («Sorry, but this is not possible to implement for a window manager. We lack information to identify that a window is the same as previous window»).

Et je suis d'accord, ce n'est pas faisable de façon 100% fiable en l'état; Mais ce n'est pas le sujet de mon commentaire.

Oui, on ne pouvait pas identifier une fenêtre précisément il y a 20 ans [avec X11], et aujourd'hui encore [avec Wayland] on ne peut pas.

Dans cette phrase, ce n'est pas la faute de Wayland, mais de la complexité du problème.

Ce qui est fascinant, c'est d'arriver à déduire ça de mon commentaire…

C'est déjà le cas : 95% des personnes ne sont pas des power-users, et s'en foutent royalement de faire du pixel-fucking sur leurs fenêtres.

Je parle quand même des utilisateurs qui souhaitent restaurer leur session, les autres évidemment n'ont pas de problème.

Et restaurer sa session, c'est pas forcément le power-user, juste celui qui a ses habitudes de travail et n'a pas envie de tout lancer et remettre sur le bon écran chaque matin.

Oui, c'est un bug kwin, initialement uniquement sur X11 bien sûr.

Grossièrement, la difficulté est d'identifier de façon fiable les fenêtres, afin de pouvoir restaurer leur position/dimension. C'est ce qui a empêché l'implémentation il y a 20 ans, et aujourd'hui encore le protocole Wayland permettant d'associer une zone à un identifiant n'est pas encore terminé…

Je trouve qu'il y a quand même un peu de mauvaise volonté dans tout ça. Des approches partielles auraient pu être implémentées, et auraient satisfait 95% des utilisateurs:
- algo basé sur le titre (exemple d'implémentation récente)
- implémentation spécifique aux applis KDE (protocole Wayland maison, identification plus fiable des fenêtres lorsque kdelibs est utilisé…)

En complétant les cas foireux avec des règles de placement (qui existent déjà dans kwin), je suis certain qu'on arrive à un joli taux de satisfaction.

Mais non, tout du long de ce bug, pour la raison un peu fallacieuse que la fiabilité n'est pas de 100%, aucune correction partielle n'a été implémentée. Et 20 ans plus tard on en est encore au point de départ: même avec le protocole Wayland qui-va-bien, chaque appli devra être modifiée pour avoir la restauration de placement. Les toolkits Qt et GTK feront le gros du boulot, mais on ne sera toujours pas à une fiabilité de 100%, comme il y a 20 ans.

Google pouvait retravailler le code proposé il y a 3 ans… Je trouve absurde pour Google d'attendre que le format soit adopté ailleurs (Apple, Adobe, un peu Microsoft) avant de le pousser dans Chrome. Il ne faut pas se leurrer, avec l'hégémonie de ce moteur de rendu web, adopter ou non un format d'image a des conséquences très visibles sur l'utilisation de ce format à grande échelle.
Si Google avazt retravaillé le code il y a 3 ans, l'adoption de JXL serait très certainement bien plus avancée aujourd'hui.