Jean Roc Morreale a écrit 824 commentaires

Est-ce qu'il y a un équivalent au wrt one en routeur filaire ? Ça compenserait le manque de port

Ce n'est pas un algo qui faut, l'actuel fonctionne très bien sur la base réglementaire. C'est soit changer les variables de pondérations associés à chaque énergie (qui, oui, défavorise l'électrique face au gaz), soit ne plus faire un DPE mais un DPE+E pour Environnemental (l'actuel DPE n'est pas un indicateur écologique). Le premier point dépend de l'influence de tel ou tel secteur énergie, le second d'une volonté gouvernementale.

Salut, il y a une méprise sur la partie BIM : l'extension NativeIFC se base sur IfcOpenShell, comme Bonsai (ex-blender bim). La simplification principale se fait en supprimant la traduction intermédiaire dans le modèle d'objets propre à freecad.

C’est bien pour ça que le SMS n’est plus reconnu comme valide comme facteur de possession depuis quelques années et que l’authenfication du téléphone nécessite bien souvent un facteur biométrique supplémentaire

Ce n'est pas un avis universel, voici le nouveau parcours d'identification à impots.gouv.fr :

Pour vous connecter, vous devrez renseigner votre identifiant à 13 chiffres ainsi que votre mot de passe habituel. Après avoir saisi votre mot de passe, vous serez invité(e) à saisir un code de sécurité reçu par courriel ou par SMS selon votre choix. Lors de votre prochaine connexion sur ce même navigateur, celui-ci sera reconnu comme « de confiance » et le code de sécurité ne vous sera plus demandé pour une période de 1 mois.

Et comme l'identification de ce site peut servir à valider une connexion france connect sur un site tiers, ça compte triple :)

Je réagis sur "Une base de données SQL implique d'avoir un schéma, ou de s'en servir comme une base de donnée clé/valeur." juste pour le fun. Si je prend l'exemple de flowg entry:<stream name>:<timestamp in milliseconds>:<UUID v4>, un schéma PgSQL ressemblerait à ça :

-- création d'une table reprennant l'exemple de la doc flowg
CREATE TABLE flowg (
  timestamp TIMESTAMPTZ,
  pk_uuid uuid DEFAULT gen_random_uuid(),
  data JSONB
);

-- pour convertir dans un format de stockage timescaledb
SELECT create_hypertable('flowg', by_range('timestamp'));

-- pour indexer toutes les clés
CREATE INDEX idx_global ON flowg USING GIN (data);

-- pour indexer une clé particulière
CREATE INDEX idx_partial
  ON flowg ((data->>'some_key'))
  WHERE data ? 'some_key';

c'est qu'une des nombreuses solutions, on peut aussi voir des solutions en base fichier capables de manger et régurgiter des tonnes de séries temporelles :)

Mais la persistance des usages des logiciels propriétaires n’est pas sans poser de réels problèmes quant à la pérennité des données archéologiques et les archéologues commencent juste à découvrir le problème

Salut, c'est un constat qui est fait et refait depuis des décennies où les usages de SI de chantier ou de labo basés sur Hypercard, 4D, Filemaker, Access, etc. (je passe la liste des formats de PAO, DAO, SIG qui ont connu les mêmes situations) et qui ne connaît qu'une lente évolution.

Le problème de l'usage de logiciels propriétaires n'est cependant qu'un aspect de la situation où les données d'une fouille numérique de 2014 sont moins exploitables qu'une de 1874 et ses petits carnets, vu l'absence globale de normalisation des pratiques d'enregistrements et les nombreux (nombreux) systèmes d'enregistrement où l'archivage pérenne n'est pas prévu.

Salut, pour aller vers un service aux collectivités il faudrait trouver un positionnement complémentaire à celui d'Enedis dont le Portail Collectivités permet un suivi global de la conso de leurs patrimoine, mais aussi aux services de GTB/GTC utilisés par les directions gérant le patrimoine. Je n'ai pas connaissance de produits opensource sur une grosse partie de ce segment, on va généralement du capteur proprio à l'armoire de gestion proprio et ses outils proprio vers un site de dataviz proprio.

Pourtant je peux constater, depuis plus d'une décennie, que l'usage d'elastic search comme base de données est un réflexe courant chez les prestataires disposant de devs applicatifs et pas de dba, l'éditeur lui-même entretient cet usage en expliquant qu'il "centralise le stockage de vos données". C'est la même motivation qu'avec d'autres technos, celle de ne pas avoir à poser des schémas relationnels qui sont perçus comme une rigidité handicapant l'agilité.

Salut, est-ce que vous prévoyez de quoi faire la bascule sans douleur depuis l'offre de l'autre hébergeur pour les personnes n'ayant plus envie de consacrer des neurones à cette partie de la pile numérique ? ça va faire vingt ans que je n'ai pas eu à m'en soucier et je l'aurais bien fait vingt de plus

L'accès a une plâtrée d'options non disponible dans un seul format ou compression ? Par exemple, le tiff permettait de dépasser une limite de 4Gb, de tuiler pour dépasser des dimensions de 100000x1000000, etc. Même si la spécification de la compression employée ne le permet pas.

Ça reste le format de conteneur le plus mal employé mais qui, maîtrisé, répond à la plus large gamme de besoins.

Dans un TIFF, voici les méthodes de compression que je peux employer :
- JPEG
- LZW
- PACKBITS
- DEFLATE
- CCITTRLE
- CCITTFAX3
- CCITTFAX4
- LZMA
- ZSTD
- LERC
- LERC_DEFLATE
- LERC_ZSTD
- WEBP
- JEPG-XL

Chacune de ces méthodes a ses paramètres propres qui seront a adapter selon le type de données (image monobande 1bit, 4 bandes, avec ou sans pertes, etc.). Cela la comparaison compliquée vu que pour un même échantillon, on peut obtenir pléthore de résultats :)

Salut, merci pour ce retour mais le bas de page indique qu'ouvaton travaille en partenariat avec gandi, ne vont-ils pas être impacté par les changements de pratiques commerciales ?

Protonmail permet facilement d'utiliser un nom de domaine autre que celui par défaut ?

et voila pour moi le plus gros frein au changement de prestataire dns+email, la nécessité de remettre les mains dans la gestion technique. C'était inutilement pénible il y a 20 ans, ça s'est amélioré depuis ?

C'est la même DGFIP qui passe par une ESN et le G de GAFA pour une action qu'aurait pu réaliser 5 ou 6 établissements publics. Au-delà du politique potentiel, c'est plutôt la tradition de déporter toute responsabilité vers des industriels (des vrais, bien poilus) avec des solutions impeccables (sinon pourquoi auraient-elles autant de parts de marché ?), qui a des histoires de SI sanctionnés pour avoir choisi oracle, ms office, sharepoint, etc. ?

ça ne poursuit pas tous les objectifs de jubako/arx, je le pointais pour nuancer les comparaisons list/dump de la dépêche.

L'avantage ne se limite pas à aws, ça me permettrait de mettre à disposition un ensemble de fichiers qui gagnent peu à être recompressé (des images jpeg) en ayant les avantages d'une unique archive (copier, faire un chmod sur un tar plutôt que plusieurs millions de jpg) sans rendre l'accès à un sous-ensemble prohibitif. C'est la démarche des formats "cloud" comme COG, ZARR, COPC, TileDB, etc.

Salut, en ce qui concerne le fait de pouvoir accéder à un élément contenu dans un tar, le projet cotar étend le format pour permettre de ne parcourir que l'en-tête et une table de hash.

Le cas d'usage est de pouvoir mettre à disposition une archive contenant des millions de fichiers sans déclencher la facturation put/get par fichiers, de rajouter de nouveaux fichiers sans coût prohibitif, de faire un bonne grosse manipulation séquentielle sur des serveurs avec des dédés magnétiques. Et, surtout, ça reste un tar compatible avec nos habitudes :)

Vouloir être objectif ne garantit pas de l'être, par exemple "TIFF and PSD can do it, but they are proprietary formats and also don't have lossy compression.", la spec du TIFF 6 se trouve pour pas un rond, l'implémentation de référence est tout ce qui a de plus libre, on peut employer une pléthore de méthode de compression à perte dont… JPEG-XL.

J'attendais le JPEG-XL justement parce que le support par défaut dans les navigateurs était sur les rails ce qui prime sur tout un tas d'autres considérations plus techniques. C'est dommage le support dans darktable avait été intégré.

Idem, c'est la sensation de légèreté sur le vélo qui (des fois) me rappelle l'existence de ce sac.

J'ai quand même de gros doute sur la sécurisation supplémentaire qu'apporterait le physique, pas sur le plan technologique mais sur la partie "social engineering", le verrouillage de session lorsqu'on s'éloigne du pc est loin d'être systématique alors si on y ajoute une clé token qui reste branchée en permanence par facilité…

Pour ceux qui ne suivraient pas le lien, la relève est là depuis quelques années :
- Terra
- sf
- stars
- raster

Merci, je n'avais pas vu passer cette information dans les e-mails de l'éditeur appelant à célébrer cette future édition anniversaire. Je peux comprendre le calcul coût/bénéfice à remplacer une version nécessitant de surveiller plusieurs distributions par une version web avec revenu récurrent. Il n'en reste que l'outil perdra ainsi 50% de sa valeur pour moi, le support latex était assez appréciable ainsi que l'intégration à LibreOffice et Firefox, pour autant je ne suis pas certain de basculer sur un nouvel abonnement.

Implémentation JPEG2000 avec accélération GPU (fork openjpeg 2) :
https://github.com/GrokImageCompression/grok

De mémoire, je crois qu'une approche semblable au select après le from avait été tenté par ingres et son QUEL mais la suite ça a été qu'Oracle a implémenté SQL et qu'ingres a glissé vers un fin (relative la fin vu le nombre de descendants). Perso les tonnes de langages censés remplacer le SQL me font souvent l'effet d'échanger quelque chose de connu pour quelque chose d'encore plus imbitable (XQuery, SPARQL, MQL, etc.).

On peut tout à fait comparer MongoDB a PgSQL, les éditeurs y passent même du temps :
https://www.mongodb.com/compare/mongodb-postgresql
https://info.enterprisedb.com/white-paper_Get-the-Postgres-and-MongoDB-report.html

vive le datalake 42.0 !

C'est bizzare de découvrir sur mon site de suivi linuxien préféré, dans un journal HS sur une de mes activités de loisirs, un lien vers une application que je ne connaissais pas pointant vers des serveurs bientôt décommissionnés. Je vais commencer à fréquenter passionponey.net pour ne pas avoir à ajouter de nouvelles tâches à ma pile, damned !

Par curiosité, pourquoi partir sur ces formats pour du gtlf/glb ? L'avantage de ce format c'est son côté prêt à consommer par le GPU, ce que ne permettent pas les formats raster classiques. L'offre de formats est assez pléthorique (BC1 à 7, ETC1, Basis, etc.), Khronos a publié cet année KTX 2.0 et l'extension KHR_texture_basisu pour GLTF.