YBoy360 a écrit 715 commentaires

Je suis contre les régimes spéciaux, et je constate aussi que l'on est plus dans les années 70 (natalité, pyramide des ages, tout à construire… c'est sûr, c'était mieux avant).

Pour le reste, on peut faire fonctionner la planche à billets comme tu le proposes indirectement et rendre tout le monde heureux pendant 1 ou 2 ans en invitants les gens à consommer plus. Je ne suis pas d'accord. C'est un mauvais calcul sur le moyen terme économiquement et écologiquement, puis ça ne fait que repousser le problème.

Si l'anti-capitalisme c'est demander de l'argent à l'état, alors on est mal barré. L'état repose sur les individus, et non l'inverse. Il y a des solutions, mais elle nécessite un minimum de réalisme et d'équité.

j'en pense rien, mais c'est pas bien de se moquer des abrutis.

Juste un truc : le néant, contrairement au vide, n'a pas de dimension. Le grand néant n'a pas lieu d'être (et n'a pas de lieu), il vaut mieux dire "le grand vide".

Je pense la même chose. Si l'auteur ne veut pas donner les sources, est-il possible de partager l'OTT?

Un document expliquant comment arriver à ce résultat serait aussi intéressant.

C'est pas EBICS, c'est SWIFT pour les règlements..

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.

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.

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)..

L'optimisation des sauvegardes serait un plus.

je peux prendre contact via ton site ?

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.

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.

Merci, je croyais être le seul ..

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…

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..

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:

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

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…