C'est un ERP jeune, mais déjà complet : ça va des ressources humaines à la tréso (EBICS), en passant par la production et le CRM (que nous n'utilisons pas).
Très souple, et totalement Open Source (sur github).
Il utilise des composants éprouvés, comme Gradle et Postgres. le framework est séparé du fonctionnel, pour ceux habitué à Gradle, chaque module fonctionnel correspond un module Gradle. Le modèle est séparé entre les modules fonctionnels.
C'est un ERP simplement adaptable. Tu peux aussi consulter la doc https://docs.axelor.com/ pour voir si ça te plait.
les 2 sont possible mon capitaine : on peut restreindre l'installation de Flatpak à l'utilisateur root, ou pas.
Maintenant aujourd'hui, les admin s'occupent de plein de choses (faire marcher les applications métier entre autres), et l'ordinateur pro est aussi utilisé dans le cadre privé. Vouloir restreindre l'installation de programme à l'admin va être frustrant… Nous installons tous les PC, et rien n'est installé par l'utilisateur final mais je ne pense pas que cela rende le réseau tellement plus sûr. Tout le monde cède irréversiblement vers les WeeChat, Skype et autres. Il faut des solutions qui contiennent ces applications.
Certes, il y a des failles, mais elle sont bien plus difficile à mettre en oeuvre, et bien peu sont finalement exploitées. Après il y a Meltdown et Spectre, mais le code exploitant ces failles est détectable facilement statiquement ou pendant leur exécution. Malgré des millions d'application, les stores restent relativement sûr.
Dans un autre genre : Est-il simple aujourd'hui d'acheter un Wifi en entreprise qui n'accède qu'a internet (et pas au réseau local) ? Rien que ça, c'est déjà une gageure et c'est une porte bien grande ouverte aux problèmes de sécurité.
il n'y a pratiquement aucun intérêt à utiliser Flatpak pour une application Java (ni le gestionnaire de paquet de la distribution d'ailleurs), sauf à vouloir proposer d'isoler l'application, (qui est quand même l'un des gros avantage de Flatpak). Java est assez indépendant des binaires de la distribution, dispose d'une bonne stabilité binaire, et propose des gestionnaires de dépendances qui fonctionnent par application et même par dépendance (les dépendances peuvent utiliser de multiple version d'une même dépendance).
Par contre pour les applications Python, ça permet de les isoler du système de la volatilité de pip et autres. Il est très facile de casser une distribution ou un build avec pip.
J'aime bien Python (on est dimanche, mais bon), par contre rien que pour Qt, entre PyQt[45], PySide, PySide2, le tout en Python2 ou Python3, installé via pip, conda, ou le package de la distro, le tout global à la distro, qui n'utilise pas la même version de gcc ni de Qt que pip et conda, on est très loin de la simplicité du monde Java pour la gestion des dépendances.
je crois que tu voulais sans doute dire LVM à la place de LLVM. Il faut vraiment utiliser un fork pour utiliser i3 sous Ubuntu ou j'ai mal compris ?
Concernant Regolith, il semble que l'on puisse l'installer via pip ou anaconda, qu'est-ce qui empêche d'installer ça sur une Debian ou une Ubuntu classique ? Si il n'y a pas de dépendance native, ça devrait passer sans problèmes..
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)..
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).
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é.
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.
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.
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.
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.
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.
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.
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.
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…
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..
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:
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…
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.
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.
[^] # Re: Autres ERP libres
Posté par YBoy360 (site web personnel) . En réponse au journal Odoo ou ERPNext ?. Évalué à 2.
C'est un ERP jeune, mais déjà complet : ça va des ressources humaines à la tréso (EBICS), en passant par la production et le CRM (que nous n'utilisons pas).
Très souple, et totalement Open Source (sur github).
Il utilise des composants éprouvés, comme Gradle et Postgres. le framework est séparé du fonctionnel, pour ceux habitué à Gradle, chaque module fonctionnel correspond un module Gradle. Le modèle est séparé entre les modules fonctionnels.
C'est un ERP simplement adaptable. Tu peux aussi consulter la doc https://docs.axelor.com/ pour voir si ça te plait.
I use Arch BTW
[^] # Re: Bien d'accord !
Posté par YBoy360 (site web personnel) . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 1. Dernière modification le 20 octobre 2019 à 14:07.
les 2 sont possible mon capitaine : on peut restreindre l'installation de Flatpak à l'utilisateur root, ou pas.
Maintenant aujourd'hui, les admin s'occupent de plein de choses (faire marcher les applications métier entre autres), et l'ordinateur pro est aussi utilisé dans le cadre privé. Vouloir restreindre l'installation de programme à l'admin va être frustrant… Nous installons tous les PC, et rien n'est installé par l'utilisateur final mais je ne pense pas que cela rende le réseau tellement plus sûr. Tout le monde cède irréversiblement vers les WeeChat, Skype et autres. Il faut des solutions qui contiennent ces applications.
Certes, il y a des failles, mais elle sont bien plus difficile à mettre en oeuvre, et bien peu sont finalement exploitées. Après il y a Meltdown et Spectre, mais le code exploitant ces failles est détectable facilement statiquement ou pendant leur exécution. Malgré des millions d'application, les stores restent relativement sûr.
Dans un autre genre : Est-il simple aujourd'hui d'acheter un Wifi en entreprise qui n'accède qu'a internet (et pas au réseau local) ? Rien que ça, c'est déjà une gageure et c'est une porte bien grande ouverte aux problèmes de sécurité.
I use Arch BTW
[^] # Re: Découverte de flatpak
Posté par YBoy360 (site web personnel) . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 4. Dernière modification le 20 octobre 2019 à 13:36.
il n'y a pratiquement aucun intérêt à utiliser Flatpak pour une application Java (ni le gestionnaire de paquet de la distribution d'ailleurs), sauf à vouloir proposer d'isoler l'application, (qui est quand même l'un des gros avantage de Flatpak). Java est assez indépendant des binaires de la distribution, dispose d'une bonne stabilité binaire, et propose des gestionnaires de dépendances qui fonctionnent par application et même par dépendance (les dépendances peuvent utiliser de multiple version d'une même dépendance).
Par contre pour les applications Python, ça permet de les isoler du système de la volatilité de pip et autres. Il est très facile de casser une distribution ou un build avec pip.
J'aime bien Python (on est dimanche, mais bon), par contre rien que pour Qt, entre PyQt[45], PySide, PySide2, le tout en Python2 ou Python3, installé via pip, conda, ou le package de la distro, le tout global à la distro, qui n'utilise pas la même version de gcc ni de Qt que pip et conda, on est très loin de la simplicité du monde Java pour la gestion des dépendances.
I use Arch BTW
[^] # Re: Ni l'un, ni l'autre
Posté par YBoy360 (site web personnel) . En réponse au journal Atom / VSCode. Évalué à 3.
Intellij écrase tout (la base de PyCharm), est OpenSource et fonctionne sur Windows, Mac et Linux.
On ne peut pas parler d'IDE sans le mentionner.
I use Arch BTW
[^] # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?
Posté par YBoy360 (site web personnel) . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 1.
je crois que tu voulais sans doute dire LVM à la place de LLVM. Il faut vraiment utiliser un fork pour utiliser i3 sous Ubuntu ou j'ai mal compris ?
Concernant Regolith, il semble que l'on puisse l'installer via pip ou anaconda, qu'est-ce qui empêche d'installer ça sur une Debian ou une Ubuntu classique ? Si il n'y a pas de dépendance native, ça devrait passer sans problèmes..
I use Arch BTW
[^] # Re: éviter le hack du sous-dossier
Posté par YBoy360 (site web personnel) . En réponse à la dépêche Création d’un serveur de fichiers sous Ubuntu. Évalué à 5.
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
[^] # Re: Contradictions
Posté par YBoy360 (site web personnel) . En réponse au journal Au revoir, LinuxFR. Évalué à 3.
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
[^] # Re: Oh fidèle compagnon depuis 20 ans!
Posté par YBoy360 (site web personnel) . En réponse à la dépêche Thunderbird 68.0. Évalué à 7.
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
[^] # Re: Sans moi
Posté par YBoy360 (site web personnel) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 1.
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
[^] # Re: Séparation app / système
Posté par YBoy360 (site web personnel) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 2. Dernière modification le 16 juillet 2019 à 15:09.
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
[^] # Re: Sans moi
Posté par YBoy360 (site web personnel) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 1. Dernière modification le 16 juillet 2019 à 14:54.
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
[^] # Re: Sans moi
Posté par YBoy360 (site web personnel) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 2.
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
[^] # Re: Littérature
Posté par YBoy360 (site web personnel) . En réponse au journal Mais pourquoi flatpak ?. Évalué à -4.
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
[^] # Re: Si tous les gens autour de toi sont des cons ...
Posté par YBoy360 (site web personnel) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 9.
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
[^] # Re: Littérature
Posté par YBoy360 (site web personnel) . En réponse au journal Mais pourquoi flatpak ?. Évalué à -4.
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
[^] # Re: Si tous les gens autour de toi sont des cons ...
Posté par YBoy360 (site web personnel) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 4.
Merci, je croyais être le seul ..
I use Arch BTW
# Littérature
Posté par YBoy360 (site web personnel) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 2.
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
[^] # Re: Ca part d'une bonne intention
Posté par YBoy360 (site web personnel) . En réponse à la dépêche Sortie de Datafari 4.3, moteur de recherche open source pour entreprise. Évalué à 1.
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
[^] # Re: Est-ce-que c'est plus libre qu'avant ?
Posté par YBoy360 (site web personnel) . En réponse au journal une nouvelle framboise. Évalué à 4.
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
[^] # Re: conso élec, retour ?
Posté par YBoy360 (site web personnel) . En réponse au journal une nouvelle framboise. Évalué à 4.
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
[^] # Re: Est-ce-que c'est plus libre qu'avant ?
Posté par YBoy360 (site web personnel) . En réponse au journal une nouvelle framboise. Évalué à 2.
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
[^] # Re: Révision technique rapide par Christopher Barnatt
Posté par YBoy360 (site web personnel) . En réponse au journal une nouvelle framboise. Évalué à 3. Dernière modification le 24 juin 2019 à 12:10.
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
[^] # Re: J'y étais
Posté par YBoy360 (site web personnel) . En réponse au journal Les 10 ans d'Hadopi. Évalué à 5. Dernière modification le 13 juin 2019 à 16:42.
J'étais à l'assemblé national devant, puis dedans lors du second vote de la HADOPI.
Riester est ministre maintenant..
I use Arch BTW
[^] # Re: Polysémie
Posté par YBoy360 (site web personnel) . En réponse au journal Microsoft Love Linux ... et tout l'écosystème opensource .... Évalué à 3. Dernière modification le 13 juin 2019 à 02:43.
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
[^] # Re: bah ouais
Posté par YBoy360 (site web personnel) . En réponse au journal journalistes -> ça m'énerve.... Évalué à 4. Dernière modification le 11 juin 2019 à 02:27.
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