modèle android : l’application décide à quoi elle a accès, tu choisis tout d’un bloc (soit tu acceptes tout, soit tu refuses tout).
modèle apple : tu choisis ce à quoi tu laisses l’application accéder, individuellement par item et par application.
Je n’ai pas besoin qu’on réfléchisse à ma place pour voir rapidement que le modèle Apple est meilleur : c’est moi qui ai le contrôle :).
Après, avec de l’Android non standard et un téléphone rooté, il y a des solutions pour fournir des données bidons aux applis : je trouve que c’est encore mieux que le modèle apple (car là, l’appli ne peut pas le détecter et donc refuser de fonctionner).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Même si ce n'est pas une bête de course, je pense ( du moins j'en ai très largement le sentiment) que ce système est beaucoup plus respectueux de ma vie privée.
Tout dépend de ce que tu installes dessus. Le modèle de cloisonnement de données est inexistant sous SFOS (c’est à dire que toutes les applis ont accès à toutes les données « globales », contacts, appels, sms, etc.). Et je ne serais pas surpris qu’elles puissent avoir accès aux données des autres applis (en attaquant directement le système de fichier). Le système est respectueux, au sens où à ma connaissance il n’envoie rien chez jolla, mais par contre, les applis que tu installes, c’est free food. Par rapport à un AOSP sans les services googles, je pense qu’il y a du coup avantage à Android (même si le modèle android aussi est pourri, les meilleurs à ce niveau c’est Apple).
Je ne comprends d’ailleurs pas trop pourquoi ils n’investissent pas plus là-dedans : je pense qu’il y a un marché (de niche, certes, mais ils sont déjà sur une niche).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Pour du bureautique, pour pouvoir partager ses vms avec ses copains sous windows, pour la meilleure intégration du copier/coller partagé, du partage de fichiers, il y a pas mal de bonnes raisons. Tout un tas de petits détails qui font que c’est beaucoup plus confortable au quotidien.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
PS : par contre, je serai curieux qu'on m'explique la différence entre Firefox (qui reste et est MAJ dernière version) et VirtualBox (qui dégage), ai-je loupé quelque chose ou "ça dépend (à débattre suivant ton poids")?
VirtualBox n’est pas essentiel au quidam moyen, tandis qu’un navigateur web, si. Et, autre point, l’évolution des technos web impose une évolution rapide des navigateurs (quoique ça se soit un peu calmé ces derniers temps), avec un vieux navigateur certains sites n’étaient simplement plus utilisables. Côté virtualbox, il n’y a pas cette évolution fonctionnelle nécessaire qui justifie la montée de version.
En gros, firefox est une énorme exception, qui ne passe que parce qu’il n’y a aucune autre solution viable (ne pas fournir un navigateur web, c’est juste pas envisageable).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Donc mon conseil: n'utilisez pas stable sur votre desktop, sauf si vous n'allez jamais sur internet / n'interagissez jamais avec personne. Sinon, utilisez plutôt testing ou unstable
Utilisez stable quand elle vient de sortir. Unstable juste après la sortie d’une stable, il faut aimer être joueur. Testing, c’est un bon choix à partir du feature freeze. Avant, c’est risqué (certains paquets peuvent être cassés dans testing pendant très longtemps, et les mises à jour de sécurité ne sont pas garanties).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Je pense qu’il y a des gens qui veulent un OS stable (dans le sens « j’ai plus besoin d’y toucher quand je mets à jour, rien ne va casser/bouger, je suis tranquille »), tout en ayant la possibilité d’installer quelques rares logiciels « à jour » manuellement. Sinon le repository « backport » n’existerait pas.
En effet. Et rien ne t’interdit d’installer gcc 7 sur ta debian. Mais je comprends que les mainteneurs ne fassent pas d’effort en ce sens : ce n’est pas ce que fait le public visé, ce n’est pas ce que souhaitent la plupart des utilisateurs.
Si ton logiciel devient :
- important d’être mis à jour régulièrement, aussi bien en terme de technos que de sécurité
- indispensable au quotidien des utilisateurs
- avec une bonne réputation de qualité sur les mises à jour, notamment en terme de non-régression
Alors tu pourras discuter avec les mainteneurs debian pour une exception. Le seul logiciel que je connais dans ce cas est firefox (pour les définitions d’anti-virus et similaires, pour qui c’est aussi le cas, il y a un canal dédié). Pour les autres, il y a les backports si ton logiciel peut supporter d’être compilé sur un environnement d’il y a x ans où x < 3. S’il ne peut pas, il te reste d’autres canaux de distribution (par exemple : fournir un .deb sur ton propre repository).
Il y a je pense suffisamment de solutions alternatives pour que tes critiques sur le choix de stabilité fait par debian ne soient guère entendues.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Je suppose qu’il utilise des fonctionnalités de la bibliothèque standard C++17 qui ne sont donc pas disponibles (le standard C++17 n’est même pas finalisé…). Il pourrait cela dit compiler son application en liant la libstdc++ en statique (-static-libstdc++ si mes souvenirs sont bons) si c’est juste ça le soucis, et ça marcherait vraisemblablement.
Cela dit : les gens qui veulent une version « stable » ne veulent probablement pas d’une application compilée avec un support expérimental (il y a une grosse contradiction là-dessus).
Sinon, si, l’ABI change grosso merdo à chaque release majeure de GCC (donc entre la 4 et la 5, la 5 et la 6, etc.). C’est cela dit surtout au niveau de la libstdc++ que cela joue, pas du langage lui-même.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
J’ai l’impression que matrix ferait le job pour tout ça. Mais ça n’est pas encore super mature, et je n’ai pas trouvé comment créer un serveur réellement privé (c’est d’ailleurs un peu à l’opposé de la philosophie du truc…).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
C’est quand même beaucoup une question de paradigmes plutôt que de langages.
C’est intéressant d’apprendre des langages différents quand ça permet d’aborder de nouveaux paradigmes. Apprendre C# quand on connaît déjà Java… mouais… Ça ira vite, par contre on n’en retirera pas grand chose.
À côté de ça :
D’ailleurs, à ma connaissance, la plupart des gens trouvent déjà normal d’utiliser un langage pour le code métier et un autre — l’une ou l’autre variante de SQL — pour les requêtes en bases de données
On a inventé les ORMs pour entre autres éviter ça.
Mais ce n’est pas le principal soucis que je vois. Le problème de la multiplicité des langages, c’est que l’interfaçage entre eux est pauvre. Et souvent, parce qu’interfacer coûte plus cher que redévelopper, on se retrouve avec de nombreux composants dupliqués (par exemple, l’orm, justement, qui ne sera pas le même pour le module php de visualisation web que pour le module go de traitement des données). Côté produit, il faut de vraiment bons arguments pour introduire une techno « alien », parce que tu en paies le prix dans la durée.
Autrement dit, la multiplicité des langages, c’est effectivement très bien pour le programmeur, mais pour le produit, c’est souvent plus une plaie qu’autre chose.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Je dois mal m’exprimer, parce qu’il n’y a rien dans le lien que tu donnes qui réponde à ma problématique.
À moins que ta solution, ce soit de passer par une signature détachée, c’est ça ? Mais ça ne me convient pas : ça me fait deux fichiers (avec les problématiques de rapprochement qui vont avec) au lieu d’un -> c’est largement pire que mon problème de validation xsd.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
J'ai du mal à comprendre, soap pass par http, qu'est ce qui t'empêche de compresser la requête et mettre le header content encoding qui va bien?
C’est effectivement comme ça que je l’avais implémenté à l’époque.
Et en quoi c'est pas standard?
Parce que ça ne l’est pas, à ma connaissance. Je veux bien que tu me trouves le standard, sinon. Mais les différents standards relatifs à HTTP que je connais ne parlent que de compression des réponses (et c’est relativement logique : le client ne peut pas à priori savoir si le serveur supporte la compression des requêtes).
Et dernièrement, en quoi json est épargné?
json n’est pas épargné. Mais un document json est généralement plus petit que le document xml équivalent, ce qui est exactement l’avantage que je soulignais. On m’a rétorqué que « de toute façon, on compresse donc c’est pas si grave » (ce qui se tient), sauf que dans les faits, c’est loin d’être toujours vrai.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).
Ce n’est pas le cas de soap (par exemple). La compression HTTP ne s’est pendant très longtemps faite que pour la réponse (je crois que désormais il y a aussi des choses pour le faire sur la requête, mais je ne suis pas sûr que ça soit tout standardisé). J’avais développé des extensions pour de la compression de requête, vers la fin des années 2000, il n’y avait à l’époque rien de standard. Ça fonctionnait bien, mais ce n’était plus du tout interopérable, du coup (on s’en foutait car on maîtrisait le client et le serveur, mais de manière générale c’est un manque).
pas de différentiation entre attribut et valeur du nœud
Je ne comprends pas ce que tu veux dire.
La différence entre <toto attr="tutu" /> et <toto><attr>tutu</attr></toto> . Sémantiquement, c’est compliqué de savoir lequel est la « forme à utiliser ».
le fichier XML définit simplement son codage dans sa déclaration.
Oui, ça veut dire que ton parseur doit connaître tous les encodages de la terre (ou qu’on puisse lui apprendre).
En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.
Contrainte que… tu ne peux pas exprimer avec un schéma. C’est ballot, mais logique car du point de vue XML l’encodage n’est pas censé être différenciant (deux documents xml d’encodage différents mais de contenu identique une fois normalisé en utf-8 ont la même signature, par exemple). Un protocole qui impose l’encodage va quelque part à l’encontre de la norme.
En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous)
Valider uniquement avec un schéma est complètement casse gueule (cf exemple précédent :) ). C’est complètement insuffisant, tu as quand même une validation à faire en complément. L’intérêt de la validation XSD est réel, mais je ne me reposerai pas dessus, et certainement pas comme première passe avant lecture car en plus c’est coûteux. C’est plus utile en validation de données produites, par contre.
Si tu veux un exemple simple, une contrainte comme « date < date_du_jour » (contrainte métier tout à fait raisonnable) n’est pas exprimable. Au final, la validation xsd ne te dispense pas de faire ton boulot correctement.
Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI.
Par curiosité, comment tu fais quand tu as des données arborescentes à représenter dans tes fichiers de conf (ou simplement des listes) à plat ? Parce que pour l’instant, tous les trucs que j’ai vus relèvent du bricolage vraiment pas beau (cf les fichiers que pond QSettings).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
De nos jours, avec la 3D, ça tombe à 3/4 secondes par semaines, soit peut-être 20 secondes dans les bon mois!
Tiens, c’est curieux, j’étais persuadé que le passage à la 3D avait notamment été dicté par des contraintes de coût, parce que ça coûtait moins cher (càd, ça va plus vite) de faire de la 3D que de l’animation « traditionnelle ». Ça se vérifie notamment bien dans les animes, où les décors sont beaucoup réalisés en 3D pour gagner du temps (mais on ne parle pas de la même chose que la « reine des neiges » niveau qualité) – pour les personnages, il y a un mix des deux.
Du coup, tu sais ce qui a motivé le choix de l’abandon du dessin traditionnel chez Disney ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Pour faire simple :
- je génère une signature enveloppée, pas de soucis, ça marche, je sais vérifier ma signature.
En revanche, ce que je ne sais pas faire, c’est faire une validation xsd sur mon xml signé. Sur mon xml non signé, pas de soucis. Mais comme je suis sur une signature enveloppée, ça fait foirer ma validation xsd (fatalement, le nœud Signature rajouté ne figure pas dans mon xsd).
Ce n’est pas super grave, je vis bien avec, mais néanmoins si tu connais une solution (options à passer au validateur xsd ? modification du xsd ?) je suis preneur.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Signer un document modifie sa structure, et donc casse la validation xsd. Ça parait logique, mais il y a peut être effectivement une astuce que j’ignore (à la réflexion : je peux peut-être déclarer la signature comme optionnelle dans mon xsd, mais dans ce cas il faut que je me retape toute la structure ?). Sinon je peux virer la signature avant validation xsd, ça reste une solution pourrie.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Oui, c’est pas terrible. Mais à part pour des fichiers de conf, les commentaires, ça ne sert pas à grand chose. Si tu m’envoies en communication M2M des xmls avec des commentaires, c’est moi qui vais hurler :).
Perso tu m'envoie un objet avec ta technique "un array d'objet a un seul champ", tu vas recevoir un email,pas piqué des hannetons de ma part. Ca fout en l'air tout mon mapping, et quitte à me prendre la tête sur le mapping, je préfère encore me taper du xml.
J’en déduis que le concept de list<pair<int,int> > est interdit chez toi ?
Tu veux une liste ordonnée, c’est une array. Tu veux un tableau associatif, c’est un un objet. Dans ton xml, dès que tu as plusieurs types d’enfant, tu te retrouves souvent à :
(je te laisse compléter). Elle est où la différence ?
Heu, ouais, enfin xml est largement spécifie, les autres outils doivent soit implémenter la spec (pas facile, certes), soit utiliser une lib qui le fait. Autant je veux bien comprendre que certains cas à la marge passent à la trappe (bug, tout ca), autant zapper les cdata, c'est un peu gros quand même.
C’est gros, mais pourtant, plusieurs évaluateurs xpath ne me donnent pas le même résultat pour toto/text()…
la feuilles xsd est incluse DANS le document. T'envoies un doc xml a un process, et il peut valider la structure de l'arbre tout seul, et le rejeter s'il est pas bon. Ou le rejeter parce qu'il n'as pas la bonne xsd.
Je suppose que tu veux dire que la (les) feuille à xsd à utiliser est déclarée dans le document. Oui, c’est pratique car ça permet à un tiers de valider en partie les données. Par contre, c’est insuffisant car tout n’est pas exprimable avec. Se reposer uniquement là-dessus, c’est casse gueule. Mais oui, c’est pratique. Par contre, signer le document (par exemple) casse cette validation… Tout embarquer dans le même document ça n’a pas que des avantages.
Cet echange de document n'arrive pas nécessairement par http — batch job, config offline, que sais je encore.
Là c’est toi qui te limite complètement arbitrairement. Le transport est complètement agnostique aussi du point de vue json (même s’il est né sur le web et dans les navigateurs).
Après, oui, XML a aujourd’hui un écosystème beaucoup plus riche (et j’avais déjà souligné certains points dès le départ). JSON manque énormément de standardisation à ce niveau. Mais ces points peuvent être ajoutés, en partant d’un format qui est plus simple et plus efficace que XML.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
pas de commentaires possible. Ca c'est un GROS problème pour la lisibilité humaine.
Ça peut manquer. Certains (je crois même que c’est le cas de la plupart) parseurs autorisent les commentaires javascript /* */, mais là pour le coup on est hors de la norme. Dans le cas d’échanges de données, c’est pas trop gênant, dans le cas de fichiers de conf, ça l’est plus, effectivement. Cela dit, j’ai souvent vu ajouter un attribut "comment" sur certains objets, là où on veut insérer des commentaires.
l'ordre des champs n'est pas spécifié.
l’ordre des attributs ne l’est pas non plus en xml. Cf mon autre réponse plus loin à ce sujet quand tu as besoin d’un ordre.
L'exemple de base, c'est la serialization d'objet, ou la class est perdue, et ne peut pas être inclue sans faire de trucs bien crades.
Je suis curieux de savoir ce que tu appelles « bien crade ». À comparer avec sérialiser automatiquement une classe « s$ » qui est un nom de classe tout à fait valide (au moins en c++ et java) mais un nom de nœud xml tout à fait invalide… Et de la nécessité des [CDATA] suivant le contenu, ce qui peut te péter pas mal d’outils qui n’en tiendront pas compte parce que ça te rajoute un nœud supplémentaire dans ton arbre dom…
bon courage pour intégrer […] la validation xsd sans tout peter.
Ça existe déjà. Par contre, ce n’est pas standardisé comme peut l’être xsd. Et c’est effectivement un problème pour l’instant.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
ws = webservice
scaler linéairement = augmentation linéaire du temps de traitement avec la taille des données. Ici on a plutôt l’impression que c’est exponentiel.
Sinon, comme barmic, je dois bien dire que je ne comprends pas grand chose. Au langage sparql, déjà, à la fin de la lecture de la dépêche je ne suis pas sûr de savoir écrire une requête simple (même après la deuxième lecture). Fondamentalement, ça me rappelle ce qu’on pouvait faire avec prolog, avec une syntaxe encore plus obscure.
Sinon, par rapport au croisement de données inter-site, logiquement, les croisements ne vont fonctionner que si tout le monde utilise les mêmes noms d’attributs. Or, dans les exemples, je vois que tout est en français. C’est traduit, ou bien chacun fait ce qu’il veut, il n’y a pas de norme établie ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Donc tu n'as pas bien lu mon post qui était concentré sur les cas d'usages "business" ou "machine to machine" dans lesquels on se cogne pas mal de la lisibilité par un humain.
Je répondais plutôt à Dabowl_75, effectivement. Mais puisque tu rebondis sur le machine to machine, XML n’est pas spécialement un bon choix de ce point de vue : on se cogne de la lisibilité par un humain, et par contre on se tape un bruit énorme. Au final, tu paies de la cpu et de la bande passante pour rien. Il existe bien des « binary XML » pour corriger ces défauts, mais malheureusement rien de standard (contrairement à BSON qui est un standard unique).
Après, XML est un standard établi, et très répandu. Comme tout standard, il lui faudra du temps pour être remplacé, et il subsistera très certainement très longtemps (il est tellement présent dans l’écosystème java que je le vois mal y disparaître). En revanche, côté web, c’est clairement le json qui s’impose (plus grand monde ne fait de l’ajax, et de la même manière, SOAP n’est considéré comme à utiliser que quand il n’y a pas le choix, à cause de l’intégration à de l’existant).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Json a quelques avantages intrinsèques par rapport à xml :
- meilleur rapport signal / bruit (moins d’octets perdus)
- pas de différentiation entre attribut et valeur du nœud
- encodage fixé par la norme
- types de base existants dans le langage (liste, flottants, chaînes), faisant partie de la norme, là où XML n’a que des chaînes
XML a un avantage intrinsèque par rapport à JSON : différentiation entre le nom d’un nœud et ses attributs.
Ensuite, les namespace manquent à JSON (je n’ai rien vu de standardisé), et côté schémas, XML garde l’avantage. Idem côté signatures, où la encore il n’y a rien de standardisé en JSON. Je ne considère pas que ne pas avoir d’équivalent à XSLT pour JSON soit un manque, par contre :).
Néanmoins, les défauts de JSON peuvent être corrigés dans la mesure où ce sont des manques, là où ceux de XML ne le peuvent pas, car ils sont intrinsèques au format. XML a encore son utilité aujourd’hui, mais JSON a tous les atouts pour le remplacer dans tous les domaines : c’est un meilleur compromis lisibilité humaine / machine que ne l’est XML.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Franchement, qu'ils n'aiment pas quand un développeur arrive, propose un patch qui ajoute des #ifdef de partout dans le code et produit un binaire tout buggé pour Windows, c'est un peu compréhensible.
Y a-t-il des essais pour le faire fonctionner via la couche « linux subsystem » présente dans windows 10 ? Bien que largement sous-optimal par rapport à une version native, c’est aussi beaucoup de boulot en moins et beaucoup plus facile à faire de manière moins intrusive.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Aux confins de l'extrême...
Posté par whity . En réponse à la dépêche Sortie de Replicant 6.0. Évalué à 1.
modèle android : l’application décide à quoi elle a accès, tu choisis tout d’un bloc (soit tu acceptes tout, soit tu refuses tout).
modèle apple : tu choisis ce à quoi tu laisses l’application accéder, individuellement par item et par application.
Je n’ai pas besoin qu’on réfléchisse à ma place pour voir rapidement que le modèle Apple est meilleur : c’est moi qui ai le contrôle :).
Après, avec de l’Android non standard et un téléphone rooté, il y a des solutions pour fournir des données bidons aux applis : je trouve que c’est encore mieux que le modèle apple (car là, l’appli ne peut pas le détecter et donc refuser de fonctionner).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Aux confins de l'extrême...
Posté par whity . En réponse à la dépêche Sortie de Replicant 6.0. Évalué à 1.
Tout dépend de ce que tu installes dessus. Le modèle de cloisonnement de données est inexistant sous SFOS (c’est à dire que toutes les applis ont accès à toutes les données « globales », contacts, appels, sms, etc.). Et je ne serais pas surpris qu’elles puissent avoir accès aux données des autres applis (en attaquant directement le système de fichier). Le système est respectueux, au sens où à ma connaissance il n’envoie rien chez jolla, mais par contre, les applis que tu installes, c’est free food. Par rapport à un AOSP sans les services googles, je pense qu’il y a du coup avantage à Android (même si le modèle android aussi est pourri, les meilleurs à ce niveau c’est Apple).
Je ne comprends d’ailleurs pas trop pourquoi ils n’investissent pas plus là-dedans : je pense qu’il y a un marché (de niche, certes, mais ils sont déjà sur une niche).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Pourquoi X86 (Intel)
Posté par whity . En réponse à la dépêche Un pas en avant pour les serveurs libres : le projet NERF. Évalué à 4.
Ok, ce n’est pas du neuf.
Ça reste complètement imbattable comme tarif (750$, c’est même pas le prix du processeur). Vous avez récupéré un stock tombé du camion, ou bien ? :)
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Base stable et application rolling
Posté par whity . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 5. Dernière modification le 30 juin 2017 à 15:04.
Pour du serveur, probablement pas.
Pour du bureautique, pour pouvoir partager ses vms avec ses copains sous windows, pour la meilleure intégration du copier/coller partagé, du partage de fichiers, il y a pas mal de bonnes raisons. Tout un tas de petits détails qui font que c’est beaucoup plus confortable au quotidien.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Pourquoi X86 (Intel)
Posté par whity . En réponse à la dépêche Un pas en avant pour les serveurs libres : le projet NERF. Évalué à 2.
Où ?
64 GiB de RAM ça coûte pas loin des 750$, et encore, pas en ECC. Il manque pas un chiffre devant ou derrière ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Virtualbox ?
Posté par whity . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 5.
VirtualBox n’est pas essentiel au quidam moyen, tandis qu’un navigateur web, si. Et, autre point, l’évolution des technos web impose une évolution rapide des navigateurs (quoique ça se soit un peu calmé ces derniers temps), avec un vieux navigateur certains sites n’étaient simplement plus utilisables. Côté virtualbox, il n’y a pas cette évolution fonctionnelle nécessaire qui justifie la montée de version.
En gros, firefox est une énorme exception, qui ne passe que parce qu’il n’y a aucune autre solution viable (ne pas fournir un navigateur web, c’est juste pas envisageable).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Utilisation bureau.
Posté par whity . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 9.
Utilisez stable quand elle vient de sortir. Unstable juste après la sortie d’une stable, il faut aimer être joueur. Testing, c’est un bon choix à partir du feature freeze. Avant, c’est risqué (certains paquets peuvent être cassés dans testing pendant très longtemps, et les mises à jour de sécurité ne sont pas garanties).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Vivement la suivante
Posté par whity . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 7.
En effet. Et rien ne t’interdit d’installer gcc 7 sur ta debian. Mais je comprends que les mainteneurs ne fassent pas d’effort en ce sens : ce n’est pas ce que fait le public visé, ce n’est pas ce que souhaitent la plupart des utilisateurs.
Si ton logiciel devient :
- important d’être mis à jour régulièrement, aussi bien en terme de technos que de sécurité
- indispensable au quotidien des utilisateurs
- avec une bonne réputation de qualité sur les mises à jour, notamment en terme de non-régression
Alors tu pourras discuter avec les mainteneurs debian pour une exception. Le seul logiciel que je connais dans ce cas est firefox (pour les définitions d’anti-virus et similaires, pour qui c’est aussi le cas, il y a un canal dédié). Pour les autres, il y a les backports si ton logiciel peut supporter d’être compilé sur un environnement d’il y a x ans où x < 3. S’il ne peut pas, il te reste d’autres canaux de distribution (par exemple : fournir un .deb sur ton propre repository).
Il y a je pense suffisamment de solutions alternatives pour que tes critiques sur le choix de stabilité fait par debian ne soient guère entendues.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Vivement la suivante
Posté par whity . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 5.
Je suppose qu’il utilise des fonctionnalités de la bibliothèque standard C++17 qui ne sont donc pas disponibles (le standard C++17 n’est même pas finalisé…). Il pourrait cela dit compiler son application en liant la libstdc++ en statique (-static-libstdc++ si mes souvenirs sont bons) si c’est juste ça le soucis, et ça marcherait vraisemblablement.
Cela dit : les gens qui veulent une version « stable » ne veulent probablement pas d’une application compilée avec un support expérimental (il y a une grosse contradiction là-dessus).
Sinon, si, l’ABI change grosso merdo à chaque release majeure de GCC (donc entre la 4 et la 5, la 5 et la 6, etc.). C’est cela dit surtout au niveau de la libstdc++ que cela joue, pas du langage lui-même.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Solutions techniques ?
Posté par whity . En réponse à la dépêche Expérience(s) de télétravail. Évalué à 2.
J’ai l’impression que matrix ferait le job pour tout ça. Mais ça n’est pas encore super mature, et je n’ai pas trouvé comment créer un serveur réellement privé (c’est d’ailleurs un peu à l’opposé de la philosophie du truc…).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Juste pour la discussion...
Posté par whity . En réponse à la dépêche Appel à conférences PolyConf 17 à Paris (7 au 9 juillet) : « The Universe of Programming Languages ». Évalué à 1.
C’est quand même beaucoup une question de paradigmes plutôt que de langages.
C’est intéressant d’apprendre des langages différents quand ça permet d’aborder de nouveaux paradigmes. Apprendre C# quand on connaît déjà Java… mouais… Ça ira vite, par contre on n’en retirera pas grand chose.
À côté de ça :
On a inventé les ORMs pour entre autres éviter ça.
Mais ce n’est pas le principal soucis que je vois. Le problème de la multiplicité des langages, c’est que l’interfaçage entre eux est pauvre. Et souvent, parce qu’interfacer coûte plus cher que redévelopper, on se retrouve avec de nombreux composants dupliqués (par exemple, l’orm, justement, qui ne sera pas le même pour le module php de visualisation web que pour le module go de traitement des données). Côté produit, il faut de vraiment bons arguments pour introduire une techno « alien », parce que tu en paies le prix dans la durée.
Autrement dit, la multiplicité des langages, c’est effectivement très bien pour le programmeur, mais pour le produit, c’est souvent plus une plaie qu’autre chose.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 1.
Je dois mal m’exprimer, parce qu’il n’y a rien dans le lien que tu donnes qui réponde à ma problématique.
À moins que ta solution, ce soit de passer par une signature détachée, c’est ça ? Mais ça ne me convient pas : ça me fait deux fichiers (avec les problématiques de rapprochement qui vont avec) au lieu d’un -> c’est largement pire que mon problème de validation xsd.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 1.
C’est effectivement comme ça que je l’avais implémenté à l’époque.
Parce que ça ne l’est pas, à ma connaissance. Je veux bien que tu me trouves le standard, sinon. Mais les différents standards relatifs à HTTP que je connais ne parlent que de compression des réponses (et c’est relativement logique : le client ne peut pas à priori savoir si le serveur supporte la compression des requêtes).
json n’est pas épargné. Mais un document json est généralement plus petit que le document xml équivalent, ce qui est exactement l’avantage que je soulignais. On m’a rétorqué que « de toute façon, on compresse donc c’est pas si grave » (ce qui se tient), sauf que dans les faits, c’est loin d’être toujours vrai.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 1.
Ce n’est pas le cas de soap (par exemple). La compression HTTP ne s’est pendant très longtemps faite que pour la réponse (je crois que désormais il y a aussi des choses pour le faire sur la requête, mais je ne suis pas sûr que ça soit tout standardisé). J’avais développé des extensions pour de la compression de requête, vers la fin des années 2000, il n’y avait à l’époque rien de standard. Ça fonctionnait bien, mais ce n’était plus du tout interopérable, du coup (on s’en foutait car on maîtrisait le client et le serveur, mais de manière générale c’est un manque).
La différence entre
<toto attr="tutu" />et<toto><attr>tutu</attr></toto>. Sémantiquement, c’est compliqué de savoir lequel est la « forme à utiliser ».Oui, ça veut dire que ton parseur doit connaître tous les encodages de la terre (ou qu’on puisse lui apprendre).
Contrainte que… tu ne peux pas exprimer avec un schéma. C’est ballot, mais logique car du point de vue XML l’encodage n’est pas censé être différenciant (deux documents xml d’encodage différents mais de contenu identique une fois normalisé en utf-8 ont la même signature, par exemple). Un protocole qui impose l’encodage va quelque part à l’encontre de la norme.
Valider uniquement avec un schéma est complètement casse gueule (cf exemple précédent :) ). C’est complètement insuffisant, tu as quand même une validation à faire en complément. L’intérêt de la validation XSD est réel, mais je ne me reposerai pas dessus, et certainement pas comme première passe avant lecture car en plus c’est coûteux. C’est plus utile en validation de données produites, par contre.
Si tu veux un exemple simple, une contrainte comme « date < date_du_jour » (contrainte métier tout à fait raisonnable) n’est pas exprimable. Au final, la validation xsd ne te dispense pas de faire ton boulot correctement.
Par curiosité, comment tu fais quand tu as des données arborescentes à représenter dans tes fichiers de conf (ou simplement des listes) à plat ? Parce que pour l’instant, tous les trucs que j’ai vus relèvent du bricolage vraiment pas beau (cf les fichiers que pond QSettings).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Avancement ?
Posté par whity . En réponse à la dépêche ZeMarmot : compte‐rendu de fin 2016 et appels aux dons. Évalué à 1.
Tiens, c’est curieux, j’étais persuadé que le passage à la 3D avait notamment été dicté par des contraintes de coût, parce que ça coûtait moins cher (càd, ça va plus vite) de faire de la 3D que de l’animation « traditionnelle ». Ça se vérifie notamment bien dans les animes, où les décors sont beaucoup réalisés en 3D pour gagner du temps (mais on ne parle pas de la même chose que la « reine des neiges » niveau qualité) – pour les personnages, il y a un mix des deux.
Du coup, tu sais ce qui a motivé le choix de l’abandon du dessin traditionnel chez Disney ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 1.
Pour faire simple :
- je génère une signature enveloppée, pas de soucis, ça marche, je sais vérifier ma signature.
En revanche, ce que je ne sais pas faire, c’est faire une validation xsd sur mon xml signé. Sur mon xml non signé, pas de soucis. Mais comme je suis sur une signature enveloppée, ça fait foirer ma validation xsd (fatalement, le nœud Signature rajouté ne figure pas dans mon xsd).
Ce n’est pas super grave, je vis bien avec, mais néanmoins si tu connais une solution (options à passer au validateur xsd ? modification du xsd ?) je suis preneur.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
Plutôt que d’indiquer la spec (que je connais vaguement pour l’avoir mise en œuvre), je veux bien que tu pointes le paragraphe précis.
Parce que là, j’en suis à :
« element Signature: Schemas validity error : Element '{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected. Expected is one of { … } ».
Signer un document modifie sa structure, et donc casse la validation xsd. Ça parait logique, mais il y a peut être effectivement une astuce que j’ignore (à la réflexion : je peux peut-être déclarer la signature comme optionnelle dans mon xsd, mais dans ce cas il faut que je me retape toute la structure ?). Sinon je peux virer la signature avant validation xsd, ça reste une solution pourrie.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 1.
Oui, c’est pas terrible. Mais à part pour des fichiers de conf, les commentaires, ça ne sert pas à grand chose. Si tu m’envoies en communication M2M des xmls avec des commentaires, c’est moi qui vais hurler :).
J’en déduis que le concept de
list<pair<int,int> >est interdit chez toi ?Tu veux une liste ordonnée, c’est une array. Tu veux un tableau associatif, c’est un un objet. Dans ton xml, dès que tu as plusieurs types d’enfant, tu te retrouves souvent à :
(je te laisse compléter). Elle est où la différence ?
C’est gros, mais pourtant, plusieurs évaluateurs xpath ne me donnent pas le même résultat pour toto/text()…
Je suppose que tu veux dire que la (les) feuille à xsd à utiliser est déclarée dans le document. Oui, c’est pratique car ça permet à un tiers de valider en partie les données. Par contre, c’est insuffisant car tout n’est pas exprimable avec. Se reposer uniquement là-dessus, c’est casse gueule. Mais oui, c’est pratique. Par contre, signer le document (par exemple) casse cette validation… Tout embarquer dans le même document ça n’a pas que des avantages.
Là c’est toi qui te limite complètement arbitrairement. Le transport est complètement agnostique aussi du point de vue json (même s’il est né sur le web et dans les navigateurs).
Après, oui, XML a aujourd’hui un écosystème beaucoup plus riche (et j’avais déjà souligné certains points dès le départ). JSON manque énormément de standardisation à ce niveau. Mais ces points peuvent être ajoutés, en partant d’un format qui est plus simple et plus efficace que XML.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
En fait, tu travailles à la RATP, c’est ça ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
Ça peut manquer. Certains (je crois même que c’est le cas de la plupart) parseurs autorisent les commentaires javascript /* */, mais là pour le coup on est hors de la norme. Dans le cas d’échanges de données, c’est pas trop gênant, dans le cas de fichiers de conf, ça l’est plus, effectivement. Cela dit, j’ai souvent vu ajouter un attribut "comment" sur certains objets, là où on veut insérer des commentaires.
l’ordre des attributs ne l’est pas non plus en xml. Cf mon autre réponse plus loin à ce sujet quand tu as besoin d’un ordre.
Je suis curieux de savoir ce que tu appelles « bien crade ». À comparer avec sérialiser automatiquement une classe « s$ » qui est un nom de classe tout à fait valide (au moins en c++ et java) mais un nom de nœud xml tout à fait invalide… Et de la nécessité des [CDATA] suivant le contenu, ce qui peut te péter pas mal d’outils qui n’en tiendront pas compte parce que ça te rajoute un nœud supplémentaire dans ton arbre dom…
Ça existe déjà. Par contre, ce n’est pas standardisé comme peut l’être xsd. Et c’est effectivement un problème pour l’instant.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 4.
Tu compares deux choses complètement différentes.
En XML comme en JSON, l’ordre des attributs n’est pas censé être important. En xml, on n’est pas censé faire de différence entre :
et
En ce qui concerne le cas :
qui conserve l’ordre, en json on l’écrira plutôt :
Qui là aussi conserve l’ordre.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Euh ???
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
ws = webservice
scaler linéairement = augmentation linéaire du temps de traitement avec la taille des données. Ici on a plutôt l’impression que c’est exponentiel.
Sinon, comme barmic, je dois bien dire que je ne comprends pas grand chose. Au langage sparql, déjà, à la fin de la lecture de la dépêche je ne suis pas sûr de savoir écrire une requête simple (même après la deuxième lecture). Fondamentalement, ça me rappelle ce qu’on pouvait faire avec prolog, avec une syntaxe encore plus obscure.
Sinon, par rapport au croisement de données inter-site, logiquement, les croisements ne vont fonctionner que si tout le monde utilise les mêmes noms d’attributs. Or, dans les exemples, je vois que tout est en français. C’est traduit, ou bien chacun fait ce qu’il veut, il n’y a pas de norme établie ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 4.
Je répondais plutôt à Dabowl_75, effectivement. Mais puisque tu rebondis sur le machine to machine, XML n’est pas spécialement un bon choix de ce point de vue : on se cogne de la lisibilité par un humain, et par contre on se tape un bruit énorme. Au final, tu paies de la cpu et de la bande passante pour rien. Il existe bien des « binary XML » pour corriger ces défauts, mais malheureusement rien de standard (contrairement à BSON qui est un standard unique).
Après, XML est un standard établi, et très répandu. Comme tout standard, il lui faudra du temps pour être remplacé, et il subsistera très certainement très longtemps (il est tellement présent dans l’écosystème java que je le vois mal y disparaître). En revanche, côté web, c’est clairement le json qui s’impose (plus grand monde ne fait de l’ajax, et de la même manière, SOAP n’est considéré comme à utiliser que quand il n’y a pas le choix, à cause de l’intégration à de l’existant).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 6.
Json a quelques avantages intrinsèques par rapport à xml :
- meilleur rapport signal / bruit (moins d’octets perdus)
- pas de différentiation entre attribut et valeur du nœud
- encodage fixé par la norme
- types de base existants dans le langage (liste, flottants, chaînes), faisant partie de la norme, là où XML n’a que des chaînes
XML a un avantage intrinsèque par rapport à JSON : différentiation entre le nom d’un nœud et ses attributs.
Ensuite, les namespace manquent à JSON (je n’ai rien vu de standardisé), et côté schémas, XML garde l’avantage. Idem côté signatures, où la encore il n’y a rien de standardisé en JSON. Je ne considère pas que ne pas avoir d’équivalent à XSLT pour JSON soit un manque, par contre :).
Néanmoins, les défauts de JSON peuvent être corrigés dans la mesure où ce sont des manques, là où ceux de XML ne le peuvent pas, car ils sont intrinsèques au format. XML a encore son utilité aujourd’hui, mais JSON a tous les atouts pour le remplacer dans tous les domaines : c’est un meilleur compromis lisibilité humaine / machine que ne l’est XML.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Bien, mais peut mieux faire
Posté par whity . En réponse à la dépêche darktable 2.2.0. Évalué à 1.
Y a-t-il des essais pour le faire fonctionner via la couche « linux subsystem » présente dans windows 10 ? Bien que largement sous-optimal par rapport à une version native, c’est aussi beaucoup de boulot en moins et beaucoup plus facile à faire de manière moins intrusive.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0