abriotde a écrit 985 commentaires

  • # Que la force soit avec le libre

    Posté par  . En réponse à la dépêche Bonne année 2023 !. Évalué à 2. Dernière modification le 02 janvier 2023 à 12:52.

    Nous souhaitons une année riche en projets libres, que l'open-source soit favorisé au sein des entreprises (et des administrations), qu'elles y contribuent…

    Parmis les grand projet qui émmergent :
    1) l'intelligence artificielle avec OpenAI en tête.
    2) RISC-V

    Et toutes les valeurs sûre (Linux, Rust… )

  • [^] # Re: awk / uniq / grep / wc

    Posté par  . En réponse au message Recherche commande. Évalué à 1.

    J'avoue, je n'ai pas testé, c'est du pur de tête (je n'ai même pas checker la syntaxe d'ou mon erreur du END).

  • [^] # Re: awk / uniq / grep / wc

    Posté par  . En réponse au message Recherche commande. Évalué à 2. Dernière modification le 26 décembre 2022 à 20:04.

    ou

    awk 'nb=0;old="" $3!=old{nb++; old=$3} end{print("result is "(nb/2))}'

  • # awk / uniq / grep / wc

    Posté par  . En réponse au message Recherche commande. Évalué à 2.

    awk '{print $3}'| uniq | grep "+" | wc -l
    
  • [^] # Re: Flash

    Posté par  . En réponse au sondage La pire tentative de web dynamique fut.... Évalué à 6.

    Il n'empêche qu'il n'a pas été retenu actuellement. Il est donc une tentative même s'il a eu une bonne heure de gloire.
    Le côté "commercial" est d'ailleurs la raison principale pour laquelle il n'a pas été retenu.
    Pour moi son pire défaut était qu'il n'existait pas de moyen gratuit (libre) de développer en Flash. Il a juste exister des petites possibilitées.

    Mais c'était relativement bien compatible avec Linux… Contrairement aux "plugin" IE qui ne fonctionnaient que sous IE.

    On a échappé aux extensions navigateurs… Car ce fût à un moment bien en place. "Installe l'extension" pour utiliser tel fonctionnalité. Et ce install n'était possible que si l'on avait IE sur Windows (Avec IE sur Wine ça marchait pas)

  • [^] # Re: Vivement le natif

    Posté par  . En réponse au lien Décodeur de JPEG-XL en JavaScript avec du WebAssembly. Évalué à 2.

    Plus que du test, plus généralement, il peut toujours y avoir des navigeurs/OS qui ne supportent pas tel ou tel encodage. On peut alors avoir le décodeur en WASM disponible au téléchargement (détecté automatiquement). Cela permet de stocker les images/vidéos dans un format optimal sans se soucier de les avoir aussi dans un autre format pour compatibilité.

  • # Alors je reste sur Mastodon.social

    Posté par  . En réponse au lien Si vous êtes sur mastodon.social ou mastodon.online, ceci peut vous concerner. Évalué à 2.

    Perso ce que je veux, c'est de la liberté d'expression avec la sécurité de l'open-source décentralisé. Je n'ai jamais vu de haine en 5 ans sur Mastodon.social (il faut dire que je ne suis pas grand chose, que ce qui m'intéresse).
    Quand j'entends ce témoignage, ce que je comprends c'est que sur Pialle.fr (entre autre), c'est censuré entre autre par la France (mais pas que, il y a sans doute du zèle en plus) alors je n'ai certainement pas envie de me couper du monde :D

  • [^] # Re: Discussion sur HN

    Posté par  . En réponse au lien Scaling Mastodon is Impossible. Évalué à 2.

    Je veux dire noyau d'OS. A un moment il faut bein tout centraliser et Linus Torwarld qui merge les branches. Et pourtant le développement du noyau (grâce à GIT) est bien décentralisé.

  • [^] # Re: Discussion sur HN

    Posté par  . En réponse au lien Scaling Mastodon is Impossible. Évalué à 3.

    Je suis tout à fait d'accord. Il est bien mieux de confronter les idées cela permet de nuancer les propos de chacun et d'en rester au fait.
    Inévitablement il y a des tensions mais les tensions/combats ne sont pas mauvaises c'est quand on en vient à mépriser l'autres et a atteindre à son intégrité qu'il y a problème.

    Toutefois le cas de Mastodon est largement différent, on parle de serveurs / communauté certes indépendantes mais qui se parlent entre elles (il y a un protocol). Les serveurs sont décentralisés mais juste car le but n'est pas de produire un produit unique… A l'inverse d'une encyclopédie.
    Dans le fond la décentralisation c'est mieux mieux (plus résilient (aux problèmes technique mais aussi aux fuites de données privées), plus scalable… ) mais évidemment qu'il faut parfois merger pour obtenir un produit unique comme une encyclopédie ou un OS Linux.

  • [^] # Re: Pourquoi

    Posté par  . En réponse au lien DuckDB: une base de données embarquée pour ceux qui en ont mare de sqlite. Évalué à 2.

    Je pense que c'est un peu une auto-dérision ce "The Rule". Sans doute que les fondateurs sont chrétiens mais je ne crois pas une seconde qu'il soit appliqué.

    Do not murder.

    Je suis un meurtrier/pédophile je vais donc voir DuckDB, là bas car on s'en tape de l'éthique :D

  • [^] # Re: Ce que Mastodon devrait procurer au minimum

    Posté par  . En réponse au lien 4 fonctionnalités de Twitter que Mastodon ferait mieux de ne pas avoir. Évalué à 2. Dernière modification le 07 novembre 2022 à 13:02.

    intérêt d'un réseau social c'est l'ouverture sur le monde, […] rester entre soi n'a guère d'intérêt.

    Ce n'est pas anti-nomique. Tu peux très bien avoir un réseau social pour rester connecter à tes amis/liste d'intérêt sans vouloir être perturbé par les autres. C'est être connecté au monde limité à ceux que tu connais qu'il soit ici ou ailleurs.

    Si tu veux te tenir informer, il y a des journaux et autres, mais c'est pareil si tu t'abonne à un journal ce n'est pas pour recevoir la pub d'un que tu n'aimes pas.

    Cela pose d'ailleurs un problème d'éthique. Sur quels critères tu pousse des articles indésirés? De la pub? De la propagande? Je ne vois pas d'autres raisons.

  • [^] # Re: "decentralized autonomous organization" ?

    Posté par  . En réponse au lien Open source sustainment and the future of Gitea . Évalué à 7.

    Justement avec la licence MIT tu fais ce que tu veux. Tu peux changer la licence pour proprio ou GPL..

  • [^] # Re: développement interminable

    Posté par  . En réponse au lien "Wayland ne sauvera pas le bureau Linux", par un dev Wayland déçu. Évalué à 2.

    En intra entreprise le téléphone n'est clairement pas le moyen le plus simple aujourd'hui pour autant il y en a encore…
    J'aurais pu parler du VoIP… Ce n'est qu'un exemple mais il y en a plein quand tu regardes dans les entreprises et autres organisations humaines. Allez, un autre : la déclaration d'impôt numérique. Tu va me dire, oui mais ce n'est pas pareil il y a des gens qui n'ont pas de PC… Et alors, il y a des gens qui n'ont pas d'adresse postal, la réalité c'est qu'évidemment il faut assuré une certaine compatibilité un certains temps…

    Il arrive que le changement soit rapide mais alors les mécontentements sont gigantesques.

  • [^] # Re: développement interminable

    Posté par  . En réponse au lien "Wayland ne sauvera pas le bureau Linux", par un dev Wayland déçu. Évalué à 3.

    Résultat: Wayland ne s'en sort qu'en mettant à disposition une couche de compatibilité avec X11, qui fait que les problèmes qu'il était sensé faire disparaître ("X11 c'est compliqué") sont en fait toujours là, mais avec une couche logicielle de plus.

    Tu connais un projet logiciel (ou même non logiciel) d'importance qui ne soit pas comme ça? C'est un problème normal. Ce qui serait pas normal c'est que cette couche ne disparaisse jamais. Et pourtant en entreprise, cela se voit souvent. Le fax a à peine disparût, le téléphone est toujours là au sein des entreprises alors qu'il y a Teams/Skype & Co… Et je ne parle pas de l'administration française (ou d'Orange) ou les applications, procédures et loies s'empile toujours plus haut alors qu'elles sont censées être remplacées.

    Parlons d'IPV4 :D

  • [^] # Re: développement interminable

    Posté par  . En réponse au lien "Wayland ne sauvera pas le bureau Linux", par un dev Wayland déçu. Évalué à 3.

    Non, je confirme j'ai lu aussi qu'Xorg est si ce n'est non-maintenable disons truffé de patch en tout sens qui le rendent inefficaces et difficile à maintenir et surtout à faire évoluer.

    En sois vu l'ampleur de l'historique de X, l'ampleur de l'écosystème intimement lié à lui, il n'est pas étonnant que la transition soit longue et complexe.

    La véritable question serait plutôt : Y aurait-il des erreurs de conceptions fondamentales sur Wayland qui le rende trop complexe et im-maintenable lui aussi.

    De ce que j'ai l'impression c'est que beaucoup se disent, on arrivera jamais à faire un serveur d'affichage parfait qui puisse remplir tous les besoins : La tache est trop lourde et trop complexe. Si c'est juste ça, j'ai envie de dire, "Ben il y a pas trop le choix, il faut y arriver, on trouvera des solutions." Cela explique bien le stress et la longueur de développement que l'on connait.

    Car malgré tout, Wayland commence à pointer son nez avec un certain succès.

  • # Idée interessante

    Posté par  . En réponse au lien Dolt : une base de données versionnée. Évalué à 6.

    L'idée est intéressante, reste à lui trouver une application concrète. Cela ne va pas révolutionner les DB néanmoins il pourrait se trouver une niche.
    Je pense notamment pour gérer du multi-server sur un réseau instable ou aux synchronisation occasionnelles pour d'autres raisons. On créé une branche du master sur notre serveur, on merge le master par moment pour garder les informations à jour et on merge notre DB le soir dans le master. Ainsi les transactions sur notre serveur ne sont certes pas avec toutes les dernières données à jour mais on évite le goulot d'étranglement du gros serveur central et les cas de coupures réseau entre les Master et notre serveur. Et l'avantage du système c'est qu'il est décentralisé, pas besoin de configurer réellement un master et des slaves. Il peut y avoir des sous-slaves suivant les cas d'usages.

    Néanmoins, il y a peu de chance que ce soit un jour réellement utilisé.

  • [^] # Re: Ce n'est pas sous-exploité, tout va bien

    Posté par  . En réponse au journal Foehn - Exploration des données SCADA du parc éolien de la Haute Borne. Évalué à 2. Dernière modification le 19 octobre 2022 à 14:41.

    Les éoliennes doivent donc être sur-dimensionnées pour y résister, et parfois être arrêtées temporairement pour les protéger.

    Oui d'accord mais ne pourrait t'on pas installer des éolienne configurées pour offrir un max de puissance à 5-6 nœuds de vent (vitesse majoritaire du vent) quitte a perdre un peu plus lors des vents forts. Je sais la puissance disponible est exponentielle avec la vitesse du vent donc évidemment on a assez peu à récupérer à ses vitesses. Néanmoins, je pense que les éolienne seraient ainsi plus économiques à produire. Je suppose que le calcul à été fait.

    Pour ce qui est du financement, je te rejoins. On ne peut pas dire que le nucléaire n'ai pas bénéficier d'aides bien plus importantes. C'est une énergie très cher si on compte toute sa durée de vie (conception, construction, maintenance, destruction, accidents (donc assurance)) mais évidemment les gens ne regardent que la production … Je ne suis pas contre le nucléaire, mais dire qu'il est pas cher est une aberration.

  • [^] # Re: SeL4

    Posté par  . En réponse au journal KataOS, un OS sécurisé basé sur SeL4 écrit en Rust ... par Google. Évalué à 1.

    J'ai vu qu'@Elfir3 arrive à la même conclusion avec son commentaire "Nuances"

  • [^] # Re: Nuances

    Posté par  . En réponse au journal KataOS, un OS sécurisé basé sur SeL4 écrit en Rust ... par Google. Évalué à 5.

    Je dirais même plus : SeL4 est écrit en C (https://github.com/seL4/seL4/tree/master/src/kernel). Alors si KataOS se base dessus, ce n'est pas un OS écrit en Rust. Je pense qu'il part de KataOS et après possède l'interface pour coder les librairies en Rust… Il y a une diférence.

  • # SeL4

    Posté par  . En réponse au journal KataOS, un OS sécurisé basé sur SeL4 écrit en Rust ... par Google. Évalué à 4.

    SeL4 est écrit en C (https://github.com/seL4/seL4/tree/master/src/kernel). Alors si KataOS se base dessus, ce n'est pas un OS écrit en Rust. Je pense qu'il part de KataOS et après possède l'interface pour coder les librairies en Rust… Il y a une diférence.

  • [^] # Re: Combien de temps avant son abandon ?

    Posté par  . En réponse au journal KataOS, un OS sécurisé basé sur SeL4 écrit en Rust ... par Google. Évalué à 2.

    Je suis d'accord que Google lance beaucoup de projet et en développe peu jusqu'au bout. Néanmoins c'est possible.
    De toutes manière avant de se lancer à utiliser réellement un projet il faut un certains background que KataOS n'a pas évidemment.

  • [^] # Re: Quelle bonne idée

    Posté par  . En réponse au lien Héberger une base de données SQLite sur Github Pages (ou un autre hébergement statique). Évalué à -1.

    Perso je vois ça surtout comme un amusement technique de faire un peu joujou

    Perso je vois ça surtout comme une super idée économique.

    • D'un point de vue coût, c'est génial. Un site statique, ne coute rien à héberger contrairement à un site PHP/MySQL. Ainsi tu as moins besoin de pub ou dis autrement, ton site te rapporte plus d'argent.
    • D'un point de vue écologique c'est mieux car le surplus de CPU consommé par le client est négligeable compte tenu que de toutes manière son CPU tourne et consomme.
    • D'un point de vue client, le chargement est bien plus rapide. Du static répondra toujours plus rapidement qu'un traitement côté serveur. Donc évidemment qu'en latence tu y gagne. Sans compter que pour les prochaines requêtes, il ne fait même plus les appels en Ajax s'il reste sur la page de 1Ko ou qu'il navigue sur une précédemment chargé même si c'est sur des données différentes.

    Le seul bémol est pour un client "terminal" avec un PC à la config trop légère. Mais du SQLLite, ça ne va pas chercher bien loin, peut-être la RAM?

  • # Quelle bonne idée

    Posté par  . En réponse au lien Héberger une base de données SQLite sur Github Pages (ou un autre hébergement statique). Évalué à 3. Dernière modification le 14 octobre 2022 à 13:23.

    En fait si j'ai bien compris le principe. Il a compilé SQLlite en WASM, et il tourne côté client. Et en gros le serveur (100% static, sans aucun traitement) sert de disque dur pour éviter de télécharger l'entièreté de la DB. Ce sont les appels de SQLlite au système de fichier qui sont fait via le réseau au serveur.

    D'un point de vue économique et écologique, c'est top.

  • # Résister

    Posté par  . En réponse au journal La première procédure bâillon au nom du secret des affaires, c'est pour Reflets.info. Évalué à 6. Dernière modification le 13 octobre 2022 à 13:06.

    On a une seule solution le faire savoir et organiser un boycot/une campagne de dénigrement d'Altice.

    Si la réaction est importante, les prochaines sociétés réfléchiront à 2 fois avant de tenter de l'utiliser.

  • [^] # Re: En quoi c’est écologique ?

    Posté par  . En réponse au lien Cahier d'idées pour un navigateur écologique. Évalué à 1.

    Eh bien ils ont tellement alourdi le web (plus simple de faire un truc bourrin qu'un truc léger) que bien parfois la vidéo est plus légère en bande passante que le web classique.
    1) Une vidéo est téléchargé 1 fois (en plusieurs petites fois parfois) pour être regardé pendant un long moment. Alors que souvent sur le web, on zappe et reste très peu de temps sur un site. Surtout que souvent on n'a pas accès à l'article entier, on a téléchargé 20 Mo de site web/pub pour 20 secondes de sur le site.
    2) Un site web réclame souvent de multiples aller-retours, or faire une grosse requête est plus léger que de faire 10 appels requête a poids égal. Surtout s'il y a plusieurs sites en jeu. Un site c'est très souvent aussi beaucoup de petites vidéos (pub, ou vidéo du texte que l'on lit) et tout ceci est téléchargé dans tous les cas.
    3) La vidéo est consommé sur des méga-plateformes qui cherchent vraiment à optimiser le flux et tout leur système. C'est beaucoup moins le cas des journaux et autres blogs dont ce n'est pas le cœur de métier.

    Après évidemment regarder en 4K et zapper toutes les 3 minutes sera plus consommateur qu'un site comme LinuxFR qui est light.

    Je ne dis pas ça de manière absolue, la vidéo de manière générale est plus consommatrice que le web texte mais ce n'est pas toujours le cas.