Christophe a écrit 677 commentaires

Personnellement, je pense qu'un tel projet est voué à l'échec s'il est piloté par l'IA. La raison est simple, et est donnée par Chris Lattner: pour un compilateur, on ne peut se permettre la moindre erreur de génération ("unforgiving correctness requirements").

Or, c'est exactement comme ça que fonctionne l'IA: avoir un résultat qui globalement remplit les conditions données, mais tout ce qui n'est pas rigoureusement testé sera potentiellement contourné.

On le voit bien dans la liste des problèmes remontés : il y a moultes simplifications dans le code du compilateur, et tout ce qui ne faisait pas partie des tests est potentiellement faux.

L'IA va continuer à renvoyer la réponse la plus probable… pour un problème donné. Or, dès qu'on parle d'un code un peu gros, il est impossible de donner un cadre exhaustif. L'IA va alors combler les trous avec "ce qui marche", pour que les tests associés au cadre soient OK. Rien de moins, mais rien de plus…

En l'état actuel, personne ne sait ce qui manque dans CCC, ce que l'IA a contourné ou implémenté bizarrement, ce qui est implémenté avec des bugs flagrants ou des valeurs en dur. Il y en a pour des années de relecture et de convergence: autant tout jeter et reprendre de zéro, finalement.

Apparemment c'est simplement que la qualité du micro permet de parler moins fort:

How effective is the voice absorption technology?

The Skyted 320 captures your low voice in noisy environments, making it blend naturally into the >surrounding sounds. Your speech is effectively camouflaged by the ambient noise, ensuring privacy, while your voice remains clear and distinct for your listener.

Can others hear me when I use the Skyted 320 in public?

The Skyted 320 lets you speak below the ambient noise level, so your voice blends into surrounding sounds and stays covered. While people nearby can't hear you, your voice remains clear and intelligible for the person on the call.

Merci, ça me semble très bien !

Et en fait je n'ai pas résisté: j'ai tenté le coup avec un petit PKGBUILD pour Archlinux. Il a fallu patcher un peu update.py pour éviter de lancer "flatpak info" et "flatpak run", mais ensuite ça marche plutôt bien !

Note: de mon côté j'ai dû lancer bbs-popcorn avec WEBKIT_DISABLE_DMABUF_RENDERER=1 , sans doute un souci avec webkit2gtk et Xorg.

Voici le PKGBUILD:

# $Id: pkgbuild-mode.el,v 1.23 2007/10/20 16:02:14 juergen Exp $
# Maintainer: Christophe
pkgname=bbs-popcorn-git
pkgver=0.1.0beta
pkgrel=1
pkgdesc="Light Youtube wrapper with MPV player - BBS Suite"
arch=('i686' 'x86_64')
url="https://github.com/blacksamdev/BBS-Popcorn"
license=('GPL-3.0')
depends=('mpv' 'yt-dlp' 'python-gobject' 'webkit2gtk-4.1')
makedepends=('make' 'python-pip' 'git')
source=('git+https://github.com/blacksamdev/BBS-Popcorn.git'
        'patch_for_native_run.patch')
md5sums=('SKIP'
         'e7303d91f5d375c76fa210632c247ea4')

build() {

  cd $srcdir/BBS-Popcorn
  patch -p1 < $srcdir/patch_for_native_run.patch
}

package() {

  cd $srcdir/BBS-Popcorn

  make PREFIX=$pkgdir/usr/local install
}

# vim:set ts=2 sw=2 et:

et le patch:

diff --git a/src/bbs_popcorn/updater.py b/src/bbs_popcorn/updater.py
index a7e14df..a4703bf 100644
--- a/src/bbs_popcorn/updater.py
+++ b/src/bbs_popcorn/updater.py
@@ -26,17 +26,25 @@ class Updater:

     @staticmethod
     def run_host(args: list, quiet: bool = False):
+        run_args = args
+        if "io.mpv.Mpv" in args:
+          run_args = [ "mpv" ] + args[args.index("io.mpv.Mpv")+1:]
+
         if quiet:
             return subprocess.run(
-                ["flatpak-spawn", "--host"] + args,
+                run_args,
                 stdout=subprocess.DEVNULL,
                 stderr=subprocess.DEVNULL
             )
-        return subprocess.run(["flatpak-spawn", "--host"] + args)
+        return subprocess.run(run_args)

     @staticmethod
     def popen_host(args: list):
-        return subprocess.Popen(["flatpak-spawn", "--host"] + args)
+        run_args = args
+        if "io.mpv.Mpv" in args:
+          run_args = [ "mpv" ] + args[args.index("io.mpv.Mpv")+1:]
+
+        return subprocess.Popen(run_args)

     # ----------------------------
     # MPV

Vu que c'est encore en bêta je ne vais pas mettre ça sur l'AUR, afin de continuer à privilégier Flatpak en cible principale.

Bonne idée, en effet les apps Electrons peuvent être assez lourdes…

Mais du coup, serait-il possible de proposer une autre méthode d'installation que Flatpak ? Personnellement je ne l'utilise pas, et du coup installer toute la base Gnome (et donc charger ses libs en mémoire) ne me tente pas plus qu'une app Electron.

Apparemment le triptique mpv/yt-dlp/bbs-popcorn s'installe plutôt simplement, il y a peut-être moyen de juste proposer un Makefile (ou équivalent cmake ou meson, peu importe), histoire d'encourager des gens à proposer des paquets de distrib ?

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.