cluxter a écrit 200 commentaires

Mieux que ça, TheTrainLine permet surtout de comparer les différents concurrents (qui sont en train d'arriver de plus en plus en France) avec la SNCF. Et ça marche pour toute l'Europe aussi si je me souviens bien. Donc utiliser le site de la SNCF seul n'a plus trop de sens selon moi, sauf à vraiment vouloir utiliser uniquement la SNCF.

Qui réserve vraiment un vol d'avion sur le site d'une compagnie aérienne particulière ? En général on utilise plutôt des comparateurs de prix, et c'est ce que propose TheTrainLine pour les trains.

A noter que TheTrainLine prend bien en compte les cartes de réductions si on lui donne l'info, et il compare bien les tarifs en prenant en compte les réductions. C'est vraiment bien foutu.

Pour ton adresse e-mail, si tu as ton propre nom de domaine, est-ce que ça ne peut pas résoudre le problème ?

Le problème c'est l’impossibilité de récupérer quoi que ce soit quand votre compte est désactivé par des systèmes automatisés.

Je n'avais jamais pensé à ça !

Ce qui m'a toujours fait peur avec le cloud, c'est :

• la perte de données à cause de problèmes divers (cf. l'incendie d'OVH par exemple), mais AWS ou GCP sont plutôt bons sur la redondance de données, donc le risque est relativement limité, surtout si on fait des sauvegardes correctes ;

• des attaques qui pourraient modifier/détruire l'infrastructure et/ou les données, mais globalement je pense que c'est plus sécurisé qu'une infra gérée totalement par soi-même, donc ça me semble être un faux problème ;

• l'espionnage industriel divers et varié (cf. la NSA qui a des accès directs aux serveurs de Microsoft depuis très longtemps et qui utilise un certain nombre de données pour indiquer aux grandes entreprises américaines quelle stratégie à adopter pour contrecarrer par exemple Airbus, ou autres). C'est un risque réel, mais pas forcément toujours pertinent. Si l'on vend des cartouches d'imprimantes, il n'y a pas forcément beaucoup de choses à espionner ;

• le retrait d'un ou plusieurs services avec 2~4 semaines pour tout rapatrier (ça s'est vu plein de fois, notamment quand Apple a racheté du jour au lendemain des services en ligne qui ont été suspendus d'un coup).

Mais je me rends compte que pour tout ce qui est perte de données, d'infra et retrait de services, la plus grosse menace n'est pas l'incendie ou le retrait rapide, mais la suspension du compte en 1 seconde !! Ça veut dire qu'une entreprise qui aurait mis toute son infra + applis + données dans un cloud pourrait d'une seconde à l'autre perdre l'accès à tout ça. Si on est un service 100 % en ligne et qu'il n'y a pas d'infrastructure sur un autre cloud (ou en interne), ça peut signifier la mort de l'entreprise en quelques jours !

J'ai l'impression d'avoir avalé la pilule rouge d'un coup là 😅
Je sentais bien qu'il y avait une douille avec le cloud… Maintenant je sais.

Si c'est facile à mettre en œuvre, pourquoi ne pas inclure une option dans l'interface pour passer d'un mode à l'autre ?

Le problème du rendu côté client vient du fait qu'on balance des montagnes de données au client car les dévs front :
- pensent que coder avec un framework c'est plus simple (si on fait tout le temps le même type de projets qui se ressemblent énormément oui, si c'est pour un projet unique non) ;
- ont des contraintes techniques que leur manager (ou le client) leur impose ("On a pris React parce que tout le monde utilise ça, donc c'est forcément bien, c'est l'état de l'art" ou "Parce que ça a été développé par Meta donc c'est robuste") ;
- parce qu'ils s'en foutent que ton navigateur doive digérer 500 Ko ou 50 Mo de données ; passer de 50 Mo à 30 Mo pourquoi pas si ça leur prend pas trop de temps, mais faudrait pas non plus passer trop de temps à faire les choses bien (par flemme ou à cause de la pression du projet).

Si maintenant on fait du rendu côté serveur, on va se retrouver avec des dizaines de milliers de paquets npm lourdingues sur le serveur (spoiler : c'est déjà le cas), ce qui implique de mettre plus de serveurs pour absorber la charge avec tous les problèmes que ça comporte (ce qui fait pas mal de boulot en plus pour la maintenance), mais surtout ça ne va strictement rien changer à ce qu'on envoie au client. J'ai passé assez de temps dans l'écosystème webdev pour savoir qu'on continuera à balancer des dizaines de Mo au client parce que "on se prend moins la tête" et que ça n'a rien à voir avec le fait de faire du rendu côté client ou serveur.

Remarque en passant : j'ai l'impression que tous les 10 ans on revient à ce qui était fait 20 ans plus tôt en nous présentant ça comme la solution à tous nos problèmes pour ne pas travailler sur le problème de fond qui est que si on veut faire un truc performant et bien fait, ça demande du temps et du travail et qu'aucun framework ne viendra faire ça à notre place.

Question car je n'ai pas lu le RGPD de A à Z (c'est un peu long et prise de tête) et que je n'ai jusqu'ici pas vu un tel cas : serait-il légal de mettre une case à cocher (en opt-in) disant quelque chose comme :

"Je souhaite étendre le délai de non suppression de mon compte à 10 ans à partir du moment où il devient inactif"

au lieu des 3 ans légaux ?

Autrement dit, est-ce qu'on peut déroger au RGPD à partir du moment où c'est un consentement donné et demandé par l'utilisateur lui-même ?

Je ne dis pas que ça serait une bonne chose à faire, je suis juste curieux de savoir si c'est possible légalement parlant.

Le Lead Dev et le Tech Lead, on en parle ?

Merci beaucoup pour ce partage !

Cela fait plusieurs années maintenant que j'utilise Seafile et c'est vraiment le feu. À l'époque j'avais testé plusieurs outils, dont les grands clouds grand public comme Amazon Cloud (depuis disparu), Google Drive, Dropbox, etc., et toutes ces solutions étaient très mauvaises au niveau des performances, sans compter souvent le manque de support pour Linux (Dropbox tire particulièrement bien son épingle du jeu sur ce point par rapport aux autres).

Je m'étais arrêté sur Nextcloud, mais après avoir vu plusieurs fois disparaître mes fichiers, remonté le bug très sérieusement avec beaucoup d'implication et de logs, et constaté que l'équipe s'en foutait royalement, j'ai dû trouver autre chose.
Pour les rapports de bugs en question, c'est par ici et par là.

J'ai fini par tomber sur Seafile et 😱 OMG quelle révolution !! Porté sur Windows, Linux, MacOS, Android et iOS, ultra performant, open source libre (pour l'édition Communautaire qui est largement suffisante pour beaucoup de monde), performances de dingue, simple tant dans sa configuration (avec un manuel bien détaillé) que dans son utilisation (grâce au concept des bibliothèques), et surtout sans réels bugs, c'est à l'opposé de ce que j'ai connu avec Nextcloud qui veut tout faire et ne fait du coup pas les choses si bien que ça. Ce qui prenait 6h à synchroniser sous Nextcloud prend 10 min sous Seafile, montre en main, je n'exagère pas (et encore pire avec les clouds grand public).

Je n'ai aucun intérêt dans ce logiciel, j'ai juste envie de partager l'info et de le faire connaître car c'est vraiment une solution de qualité et j'aurais aimé tomber dessus plus tôt. Donc j'espère que ça permettra à d'autres d'en profiter également.

En désactivant IPv6, ça donne quoi ?

Ça ne serait pas la première fois qu'on verrait des bugs ou des lenteurs à cause de ça sur un système ou un réseau. Ça vaut clairement la peine de tester. Non pas que ce soit une solution en soi mais ça pourrait peut être aider à isoler l'origine du problème.

Un clavier façon ThinkPad avec un TrackPoint au milieu, ça serait génial.
Si on peut mettre des touches mécaniques, c'est encore plus fou.

Mozilla a successivement eu 3 APIs différentes pour les addons de Firefox et Thunderbird.
Conclusion qu'ils en ont tiré : à chaque changement, ils ont perdu énormément de parts de marché, donc aujourd'hui ils ne veulent plus changer d'API.
Ceci dit ils ne de toute façon plus beaucoup de parts de marché à perdre, alors foutu pour foutu…

Je me souviens à l'époque où les informaticiens libristes les plus convaincus autour de moi installaient Chrome partout où ils pouvaient, pour eux-mêmes, pour leur sœur, copine, parents, cousins,…

Et voici un échange type que j'avais avec eux :

"Moi : Mais pourquoi tu installes Chrome ? C'est Google derrière.
Lui : Oui mais il est vachement plus rapide que Firefox, et c'est du libre/open source, donc on sait ce que fait le code de toute façon.
Moi : Oui mais s'ils deviennent la référence parmi les navigateurs, ils nous la mettront à l'envers.
Lui : Nan mais pfff, t'es parano…".

Voilà, aujourd'hui on y est.
Maintenant on fait quoi ?

J'avais un NAS QNAP, le TS-201, et j'avais trouvé des failles de sécurité assez criantes, ainsi que plein de bugs en utilisant leurs outils.

Plus jamais de QNAP pour ma part depuis cette expérience.

Le but d'un article, c'est quand même de résumer les choses un minimum pour savoir de quoi on parle exactement. Quitte ensuite effectivement à aller approfondir le sujet avec les liens fournis. Mais en l'occurrence il n'explique pas en quoi cette proposition d'API pose problème par rapport à la situation actuelle, on est obligé d'aller voir les liens pour comprendre ça. Du coup ça revient à mon propos initial : l'article en tant que tel n'apporte pas grand-chose. Et je trouve ça dommage.

Je ne dis ni l'un ni l'autre.

Je dis que cet article (cf. le titre de mon commentaire initial) ne présente pas les choses de façon suffisamment claire et complète pour qu'on comprenne bien en quoi cette API pose (ou pas) problème.

Avec les moyens actuels, on peut savoir si l'utilisateur n'a pas interagit avec la page récemment (via les propriétés comme onmousemove) et on peut savoir si l'onglet n'est plus actif (économiseur d'écran actif ou navigateur réduit, sans distinction), mais on ne sait pas si cet état d'inactivité signifie que l'utilisateur est actif sur une autre application (donc toujours devant son écran en train de travailler mais plus sur l'onglet web) ou s'il est parti prendre une pause et que sa machine est bien inactive (économiseur d'écran actif par exemple).

Ce qu'apporte cette API, c'est de pouvoir faire cette distinction. Savoir si c'est la session de l'OS qui est active/inactive, plutôt que juste l'onglet du site web. Ça permet de surveiller l'état d'activité/d'inactivité d'un poste de travail depuis l'onglet d'un navigateur plutôt que juste l'inactivité de l'onglet web.

C'est un vrai problème de confidentialité, et c'est dommage que l'article se contente de pousser des cris d'orfraie sans expliquer réellement la différence de fonctionnement avec les outils qui existent déjà. C'est en cela que je trouve que cet article n'est pas très utile.

Franchement, je ne comprends ni l'intérêt de cet article, ni les commentaires.

Suis-je le seul à avoir entendu parler de services comme Inspectlet qui permettent d'enregistrer 100 % de ce que vous faites sur un site web (mouvements de souris, déplacements sur la page, frappes au clavier, heatmaps,…) et utilisés par tous les plus grands sites webs ?

Suis-je le seul à connaître la propriété document.body.onmousemove en JavaScript ?

On a déjà tout ce qu'il faut pour faire 100 fois pire que cette API "Idle Detection" avec les outils actuels. En fait, on peut déjà la faire depuis des lustres. L'avantage de cette API, c'est de bien délimiter le cas d'usage et d'imposer des limites lorsqu'on l'utilise. Ça a le mérite de clarifier les choses. Techniquement, on n'en a absolument pas besoin, car je le redis : on peut déjà le faire avec les standards actuels (et c'est franchement pas compliqué). Cette API est au mieux une amélioration de ce qui existe déjà, au pire inutile.

Franchement, flipper sur cette proposition d'API, c'est montrer à quel point on est ignorant de ce qui existe déjà depuis des années sur les sites webs qu'on utilise tous les jours et à quel point on est en retard sur les possibilités techniques de la surveillance actuellement.

Si vous n'êtes pas convaincus, amusez-vous 20 secondes avec la démo d'Inspectlet, vous verrez par vous-mêmes :

https://www.inspectlet.com/hello/capturedemo

Et ça n'est même pas le meilleur dans son domaine.

Pour l'administration d'un serveur, je crois que le top du top est NixOS. C'est une distrib qui est en train de prendre de l'ampleur et pour l'avoir essayée je pense que ça va continuer. Dès que j'ai un moment je passe mon serveur dessus. C'est peut être le moment pour un certain nombre d'administrateurs de s'y mettre, ou au moins de l'essayer.

Nextcloud qui semble royalement ignorer un bug critique depuis plus de 2 ans (le client de synchronisation supprime aléatoirement des répertoires entiers côté client et personne ne comprend pourquoi), malgré les cris d'orfraie de certains utilisateurs (dont moi-même) depuis tout ce temps pour les avertir que c'est une raison qui pousse les utilisateurs vers d'autres solutions : https://github.com/nextcloud/desktop/issues/260

Lorsque j'ai demandé à rouvrir un ticket lié à ce bug ce problème de conception il y a 2 ans pour travailler dessus, on m'a ignoré, puis demandé de m'assurer que mon client était à jour, puis ignoré.

Pour ma part, je suis allé tester d'autres solutions et j'ai rapidement jeté mon dévolu sur Seafile qui a changé ma vie. Ca fait moins de choses que Nextcloud, mais ça le fait parfaitement, avec une approche par commits à la git/à la CouchDB, ce qui fait qu'on garde toutes les versions d'un fichier (+ la corbeille pendant X jours si on supprime).

Mais le pire, ce n'est pas tant ce problème de conception affreux qui a posé problème, c'est la façon dont l'équipe officielle (et notamment le co-fondateur) réagit à ce problème. Ils semblent considérer ça comme un bug parmi d'autres, plutôt bénin, absolument pas prioritaire, et rien de sérieux n'a été entrepris dessus. Du coup je me dis que s'ils gèrent leurs équipes de la même façon que leurs utilisateurs, c'est peut être pas étonnant qu'on en arrive à de tels problèmes de conception.

Nextcloud m'a perdu au profit de Seafile et une chose est certaine : je ne reviendrai pas en arrière, pas tant à cause du bug en tant que tel qui rendait leur solution inutilisable dans mon cas, mais surtout à cause de la façon qu'ils ont eu de (ne pas) gérer le problème. S'ils avaient dit "OK c'est vrai que c'est critique, on va bosser dessus en priorité", j'aurais non seulement attendu patiemment d'avoir le patch même s'il avait fallut attendre longtemps, mais j'aurais aussi aidé à débugguer tout le truc. Leur réaction m'a poussé à aller voir ailleurs et pour de bon. Comme quoi les "soft skills", ça compte (aussi) beaucoup, notamment dans la gestion de projet (et dans la communication, ça va sans dire).

Et au Québec, ils ont un mot ? Car en général ils sont bien meilleurs qu'en France pour trouver de nouveaux mots et faire vivre la langue française.

Des lecteurs Québécois parmi nous ? ;)

et « duck duck goer » par vous‑même

Et « ducker » par vous-même ?
Juste une proposition.

Quelles sont les différences d'un point de vue fonctionnel entre Root As Role et les systèmes de Mandatory Access Control (comme SELinux ou AppArmor) ? Les avantages de l'un par rapport à l'autre, ou si ça n'a rien à voir, en quoi c'est fondamentalement différent ?

Merci

Pour ceux qui me moinssent, franchement je ne comprends pas pourquoi. C'est une vraie question que je pose là, je n'y mets aucun affect. Si les raisons pour lesquelles Devuan a été lancée n'existent plus, on peut légitimement se demander quel est son rôle aujourd'hui. Ce qui ne veut pas dire qu'elle ne sert plus à rien, mais que du coup ils ont dû redéfinir son rôle à un moment donné de l'histoire. Et c'est là où je demande quel est ce rôle, car je n'ai rien trouvé de clair.

En complément à cette remarque, c'est bien d'avoir de la diversité et du choix dans les distributions, c'est bien d'avoir une distribution pour chaque usage, mais d'un autre côté plus on a de distributions et moins on a d'énergie concentrée sur chaque distribution, ce qui en plus d'augmenter la fragmentation dilue également les efforts.

J'étais complètement pour Devuan à l'époque, mais si aujourd'hui les 2 points pour lesquels elle a été créée n'existent plus, alors peut-être qu'elle n'a plus de raison d'être et qu'il est temps de tourner la page. Ce n'est pas toujours une mauvaise chose, il faut parfois savoir mettre un terme à une aventure lorsqu'on est arrivé au bout. Et si Devuan n'est pas arrivée au bout de son aventure, alors SVP expliquez-moi pourquoi. C'est une vraie question (et c'est incroyable que je doive le préciser).

Bah déjà, vu l'état de l'art en matière d'interface utilisateur et des pilotes pour les mobiles, quel serait l'intérêt d'y installer autre chose qu'Android ? Si ce n'est précisément pour y développer ce qui manque.

Attention, je ne dis pas qu'Android c'est bien, mais que pour l'instant il n'y a pas à ma connaissance d'autre système capable de supporter nativement disons 80 % des mobiles, à mon grand désarroi (sans même parler de l'interface utilisateur).

Devuan est née :

1) parce qu'on voulait continuer à utiliser Debian ;
2) parce qu'on voulait continuer à utiliser Debian sans systemd et que l'équipe officielle ne voulait pas en entendre parler.

Du coup, si ces 2 points ne sont plus de la partie, j'aimerais vraiment que quelqu'un m'explique la raison d'être de Devuan aujourd'hui.

C'est quoi l'atelier d'assemblage ?