YBoy360 a écrit 756 commentaires

nous cherchons à nous débarrasser d'AD justement, nous avons 2 sites avec relation d'approbation et tout le tintouin, les administrateurs ont déjà tenté l'aventure mais sans succès, ou alors avec un résultat partiellement convainquant (c'est la même rengaine pour malheureusement trop de projets où le temps était loin de manquer)..

L'optimisation des sauvegardes serait un plus.

je peux prendre contact via ton site ?

I use Arch BTW

Moi aussi j'aime la moto (et puis le ceviche aussi, en vacance. Surtout au soleil avec un verre de rosé).

J'ai commencé avec une CR 125 à 12 ans.

Aujourd'hui comme je n'ai pas le permis, je n'ai qu'un 3 roues (qui consomme peu, un Metropolis). Ça m'empêche pas de prendre aussi le métro ou mon vélo.

Alors non seulement je passe pour un connard de motard, (alors que ce n'est qu'un scoot) par les types génériques, mais en plus je passe pour un kéké pour les types motards.

J'en déduis que comme pour pas mal de choses, qui vont par 3 (le bon, le mauvais, et le truand, les cons, les pas cons et les autres, les femmes, les hommes et les autres), il y a 3 types de profil (et non 2 et encore moins 1).

I use Arch BTW

C'est vrai que KMail version 3 (surtout pas 4) était un régal : léger, puissant (regex à tous les étages), rapide, joli et simple aussi. Enfin bref, le meilleur de ce que j'avais vu, (ça date un peu), puis Akonadi a tout défoncé.

I use Arch BTW

Normal, je suis d'accord ta diatribe modulo 1 truc : que le fautif n'est pas le gestionnaire de package qui permet de factoriser les binaires. Tu connais au moins les avantages de cette démarche ? T'en donne vraiment pas l'impression.. puis faire des packets n'est pas très compliqué pour les distributions.

Ce n'est pas tant le bordel que ça, il y a des gens pas d'accord, bah rien ne les empêche de faire différemment. Tu changeras pas ça. C'est l'essence même de l'Open Source, ou la plupart des utilisateurs n'utilise pas le binaire fourni par le développeur, mais LES SOURCES recompilé par la distribution.

I use Arch BTW

Tu peux restreindre les droits à l'utilisateur root comme pour RPM ou deb.

Question sécurité, toutes les nouvelles plateformes proposent maintenant des sandbox. Que ce soit Chrome, Windows ou Apple. Par contre, ce n'est pas transparent.

Si tu utilises libreoffice de Flatpak et que tu ouvres un csv, tu n'as pas les options dans le file chooser, puisque c'est celui par défaut de ton desktop.

I use Arch BTW

Sans gestionnaires de packets, ce serait encore 100 fois plus la merde.

Si tu veux distribuer un binaire commun à plusieurs distributions, et contrôler la diffusion de ton logiciel, sans passer par le système de packaging, tu n'as d'autre choix, dans ce cas particulier que de faire aussi mal que Windows : refiler un binaire auto extractable, gérant sa mise à jour et statique ou un appimage, un Snap, ou un package Flatpak.

La distribution de binaires, hors distribution requière une compatibilité binaire entre elles si tu veux tout faire comme Windows. Moi j'y suis favorable aussi mais pas la majorité des développeurs, donc des solutions comme Flatpak permettent de concilier tout le monde en gérant plusieurs versions de binaires simultanément.

Dans le monde Open Source, on échange les sources, pas les binaires comme sous Windows. Certains usages en pâtisse, mais il y a bien plus d'avantages.

I use Arch BTW

Les autres OS voudrait le faire et le font en partie hein.. Puis Windows est limité par l'absence de gestion des liens symboliques pour éviter le dependency hell d'il y a quelques années..

Tu reproches à Flatpak de gérer les dépendances, mais tu lui reproche la taille des chargements… Si tu veux installer 50 applications, ce n'est pas délirant de vouloir partager les librairies, c'est exactement fait pour cela, ça économise la mémoire, et tu simplifies les mises à jour de sécurité. C'est dans les guideline Unix depuis environ 40 ans. On peut reprocher la granularité des packages, mais moi je pense qu'a l'usage, leurs choix sont les bons.

Si il y a une chose où Linux est sans reproches, c'est justement la gestion des packages par les distributions. Ça ne t'empêche pas de télécharger un gros binaire statique… Mais ne prétend pas que cette solution est meilleur.

Pour en revenir à la critique principale de ce journal : t'as une Debian 8, ou une RH 6, et que tu veux installer la dernière version de Libre Office via le système de package, tu dois mettre à jour toute ta distribution. Tu consommeras encore plus de bande passante qu'avec Flatpak.

Personnellement, une distribution basée directement sur les packages Flatpak ne serait pas une mauvaise idée.

I use Arch BTW

Et sans sandbox, tu croies qu'il y aurais combien de failles ???

Personne a dit que les sandbox était invulnérable, elle tendent cependant à l'être. Dès lors que ces toutes petites failles sont réparable rapidement, il n'y a pas d'argument contre les sandboxes.

I use Arch BTW

Le problème, c'est que je trouve ta description des différents modes de distribution d'application approximative et c'est un sujet qui nécessite du doigté. Pour te convaincre, il faudrait déjà tout mettre d'équerre…

Par exemple, ton premier point technique sur Android est seulement approximativement vrai. Le SDK d'Android ressemble plus à un Framework complet qu'a la libc. Il est lui, partagé entre toutes les applications. Donc les applications ne sont pas si indépendante que ça, de plus le système d'Intent font que les applications utilise les composants d'autres applications.

Pareil pour la sandbox de flatpak, d'où l'application peut ouvrir n'importe qu'elle fichier sans l'autorisation de l'utilisateur ? Normalement, seuls les fichiers volontairement ouvert via le file chooser sont accédés.

Pour Steam, on sait tous que les assets représente au bas mot 98% de l'espace nécessaire à un jeu vidéo, et que ceux-ci ne partage rien avec le monde extérieur, si ce n'est la SDL ou OpenGL. Que l’interaction entre Steam et un jeu vidéo, c'est à peu près peanuts. Qu'est-ce que Steam vient faire à propos de l'efficacité de Flatpak… ça n'a juste rien à voir!

Bref, je cherche pas à te convaincre que flatpak c'est bien, juste qu'avec ton journal, on y voit vraiment pas clair.

I use Arch BTW

bidon

pour 1, ce n'est que pour la version Windows, ça peut-être fixé, la surface est très faible….

pour 2
Check Point says a key vulnerability that Agent Smith relies on was patched several years ago in Android. But developers need to update their apps in order to take advantage of the added protections. Evidently, many have not.

I use Arch BTW

Merci, je croyais être le seul ..

I use Arch BTW

J'aimerais avoir de la littérature sur les failles des sandbox d'Android et de Chrome, qui ne me fasse pas perdre mon temps, ne soit pas des ragots approximatif comme ce journal, qui ait moins de 5 ans, et qui n'ait pu être comblées.

Structurellement les Sandbox (hors failles cpu Intel) sont-elles bancale? ou c'est juste le besoin de s'la raconter au comptoir ?

On peut tous se logger en Root et lancer Gnome aussi…

I use Arch BTW

C'est ballot de devoir se contraindre à utiliser Docker pour enrober un war.

Surtout avec les outils de build Actuel. L'intérêt de java c'est de simplifier la distribution de sources ou de binaires..

I use Arch BTW

Les GPU de nos jours sont capable d'écrire en mémoire directement, et c'est juste ce qu'il faut.

Le fait d'initialiser le GPU avant le CPU (et avant la mémoire et le cache) permet d'avoir un affichage sans changements de contexte, comme lors du passage du bios à Grub, de Grub au Kernel, du Kernel à Xorg (si on utilise Xorg, il y aura quand même un changement de contexte, mais pas avec Wayland et autres). ARM ne spécifie pas comment doivent booter les SoC ARM, donc cette procédure est hardcodée sur le SoC hors du core ARM, que ce soit le GPU ou non. Alors pourquoi ne pas utiliser le GPU pour cette étape? Contrairement à ce qui se dit, ça ne me parait pas être "un hack immonde"… C'est bizarre, mais bon.

Certains, comme 96Boards cherche à établir des spécifications communes aux fabriquant de SoC ARM, c'est surement cette direction qu'il faut suivre pour facilité la vie des distributions..

I use Arch BTW

Non, au max c'est 1.2 ampères, par contre en fonction des périphériques USB ça peut monter. C'est un peu plus que le 3B+ par contre, niveau performance, il y a pas photo:

https://www.tomshardware.com/reviews/raspberry-pi-4-b,6193.html

I use Arch BTW

Dans un PC normal, il y a aussi le BIOS et des blobs proprios… Le BIOS permet d'avoir une séquence de boot uniforme sur plusieurs type de machines, mais il est tout aussi fermé.

Indépendamment des blobs propriétaires, je pense par contre qu'initier la séquence de boot par le GPU n'est pas choquant sur un SoC, même au contraire, je trouve ça plutôt élégant. D'ailleurs la séquence de boot des raspberry est plutôt jolie et efficace comparée à celle d'un PC, les nouveaux bios devenant totalement imbitable…

I use Arch BTW

D'après TechCrunch, ce n'est pas de l'ethernet over USB 2.0, mais du vrai ethernet.

J'avais lu un article il y a quelques mois parlant d'une version PRO avec un ASIC programmable, je ne trouve plus rien là-dessus malheureusement.

J'ajoute par rapport au journal, il y a 2 ports HDMI …

I use Arch BTW

J'étais à l'assemblé national devant, puis dedans lors du second vote de la HADOPI.

Riester est ministre maintenant..

I use Arch BTW

Comme Dieu est amour, on peut remplacer dans ton texte amour par Dieu(x optionnellement, car il(s) semble(nt) indénombrable(s) si on veut mettre tout le monde d'accord).

Autant ça fonctionne dans ton texte, autant pour le titre c'est un peu plus compliqué : Microsoft aime Linux, on peut remplacer "aime" par "a de l'amour pour" ou en inversant le sujet et le COD "est de l'amour pour".

On se retrouve avec 2 possibilités, mais l'une est forcément vrai, c'est : Linux est l'Dieu pour Microsoft.

Voila, voila, pardon famille tout ça[]

I use Arch BTW

Out of order c'est la capacité d'un CPU a regarder dans le cache instruction ce qu'il peut exécuter en parallèle. Par contre, l'écriture en mémoire se fait in order par l'issue stage (ou writeback).

Si tu as
a = x + y
b = u +/* t

Les 2 opérations et les load (typiquement 17 cycle si il faut loader depuis la mémoire, sans tlb misses) se feront en parallèle, mais a sera écrit en mémoire avant b et si x + y émet un overflow, le registre contenant b ne sera pas modifié, donc cette optimisation ooo n'est pas visible par le programme, et heureusement.

Un exemple un peu plus compliqué impliquerait des branchements (des if), les CPU moderne essai de prédire la branche la plus probable. Sur les ARM, par défaut, les Switch et les if sont exécuté comme si la condition était vrai (comme si il n'y avait pas de branchement). Le pipeline chevauche le if, lorsque la condition est connu, si il faut faire le jump, alors le pipeline est reseté (plusieurs dizaines de cycles pour les CPU moderne). Sur les processeur itanium, tu n'as carrément pas de branchement, les instructions sont toutes exécuter et discardé en fonction des besoins.

Peu importe comment fonctionne un CPU, un programme reste une suite d'instruction a exécuter dans l'ordre, peut être parallèlement, mais dans l'ordre. Ce qu'au final fait le CPU par rapport aux écritures mémoire.

I use Arch BTW

Le pipeline d'un CPU :

1- "délivre" le résultat des instructions dans leur ordre exacte d'arrivée. Sinon c'est le bordel, mais il va essayer en interne (c.a.d. de façon invisible ou de façon transparente pour le programme exécuté), de paralléliser, d'anticiper les branchements et tout un tas de conneries comme prefectcher les instructions, ma memoire, le TLB ou que sais-je.. c'est totalement traçable, prévisible et tu peux essayer de voir l'état interne du processeur, à tout instant.

2- exécuter un nombre d'instructions grossièrement constant par cycle.

Ce n'est pas le cas d'une machine quantique (bien sûr, il n'y a pas de pipeline dans un machine quantique, c'est toute la différence, faisons comme si) :

1-a tu ne peux pas observer l'état interne du pipeline d'une machine quantique, sans la stopper, et devoir recommencer le calcul
1-b tu ne peux donc pas isoler une instruction séparément des autres, toutes les parties du problème s'exécute réellement simultanément sur plusieurs cycles (c'est l'intrication qui fait l'intérêt d'un calculateur quantique).
1-c il n'y a pas d'opération de copie dans un calculateur quantique. Donc pas d'unité "issue" possible qui va copier l'état du registre interne du CPU classique vers la mémoire. le calcul est effectué "en place" (bonne chance pour trouver la condition d'arrêt, si tu connais pas le résultat cherché) ce qui implique 2-b ci-dessous.

2-a le nombre de calculs par cycle n'est pas une constante
2-b tout calcul fait à un instant donné à un impacte sur l'état du pipeline "virtuel", tout est intriqué, c.a.d. la longueur virtuelle qu'il faudrait simuler du pipeline d'un calculateur quantique est aussi long que le nombre de cycle du programme exécuté (si on modélise un ordinateur quantique avec un pipeline).

Comme ce n'est pas la même chose, ces comparaisons sont un peu tirées par les cheveux.

I use Arch BTW

On en est même très loin pour 72 : Google annonce juste avoir disposé 72 Qbits les un à côté des autres, avoir stocké un résultat puis relu ce résultat avec un taux d'erreur faible. C'est très bien, mais ça résoud très peu d'aspect du problème pour avoir quelque chose d'exploitable.

I use Arch BTW

Le problème, c'est quand les PR s'en mêlent. Là tu comprends qu'il n'y a aucun regard critique de la part de la presse.

Combien d'articles ont répété qu'IBM avait déjà commercialisé un ordinateur quantique ? Combien disent qu'intel a déjà un CPU quantique ? (Ils ont des photos, ça oui)

On ne sait même pas si il est possible d'en faire pour notre civilisation, la plupart des journalistes comprennent pas l'intérêt du calculateur quantique, mais ils t'annoncent sans aucun filtres toutes ces conneries.

Certains informaticiens ne sont pas mieux lotis, un stagiaire m'a annoncé qu'il attendait le GPU quantique..

Déjà utiliser le terme ordinateur, pour désigner ces machines, (ou calculateur) prouve que personne ne comprends vraiment le gap qu'il y a avec un ordinateur classique. Ordinateur renvoie a l'idée instructions ordonnancées ce qui est vraiment on ne peut plus trompeur pour une machine quantique.

I use Arch BTW

Tu veux dire faire de l'AOP (version générale du Proxy)?

ça se fait en Java, avec AspectJ par exemple. C'est vrai que ce n'est pas simple.

I use Arch BTW

Je pense que tu connais déjà, c'est moyen "propre" (je ne l'utilise pas des masse), il y a l'annotation Delegate directement en Groovy.

@TupleConstructor
class SelectOptionList {
    @Delegate
    List<SelectOption> selectOptions
// . . .
}

SelectOptionList s'utilise comme une liste.

I use Arch BTW