Gabin3 a écrit 87 commentaires

Dans ce cas, alea jacta est.

Je cite:

Le souci habituel posé par les comptes multiples actifs concerne les diverses manipulations possibles, comme encenser son propre contenu ou commentaire en utilisant des commentaires d'autres comptes à soi, voter massivement pour soi, ou pour ou contre quelqu'un, etc.

Et bien, il serait temps que quelque chose se fasse à ce niveau car ça devient pénible.

Je trouve cette suggestion qui n'est pas de moi, intéressante.
Demander une raison quand on clique sur inutile.

On y voit d'ailleurs que mon commentaire a subit un -1. Je vous demande en toutes honnêteté comment cela est-il juste possible?

Je cite:

À défaut de rendre visible les moinsseurs, ton approche a le mérite d'être constructive.
Je subis des moinssages étranges même quand j'apporte une aide dans les forums.

De plus, cette suggestion permettrait même de résoudre cet autre problème rapporté par un autre utilisateur et confirmé par "d'éminents" membres:

Annuler un pertinentage/inutilage

@+

note:
pour mes messages de forum moinssés
1)mikrotic dont je possède un de leurs appareils.
2) GDM pour laquelle j'apporte une solution effective qui n'a pas été infirmé et une remarque honnête sur systemd, certes, pétrie de frustration car la solution m'a pris trop de temps à trouver.

Vous espèrez vraiment ne créer aucun ressentiment?

NOTE: moins d'1 minute et déjà un -1!

T'en as pas marre de passer pour un ignorant

C'est ton opinion.

incapable de se rendre compte que sur linuxfr pas mal de dépêches "graphiques" sont écrites par des développeurs bien plus pointus et au fait que toi sur ces questions (devs de Gimp, des pilotes graphiques, de Xorg, Wayland, chercheurs en algorithmie, etc.) ?

1) Où est le rapport?
2) Les as-tu vu?
3) Ai-je répondu à ces personnes?

Ou alors tu aimes te plaindre et tu cherches sciemment le moinssage avec des blablas péremptoires de cour de récré ?

C'est ton opinion et sans éclairer mon ignorance par tes connaissances, tu ne fais ici que m'insulter et d'abuser de ton statut de modérateur.

Je me souviens avoir lu il y a quelques mois un article sur une nouvelle fonctionnalité de retouche photo

Il y a une énorme différence entre une fonctionnalité codée durant un GSoC par un étudiant et abandonnée 1 mois plus tard à une fonctionnalité soutenue par une équipe d'ingénieurs professionnels, ou alors c'est tous des glandus car ne bossant pas sur Archlinux?!
Donc oui, Gimp a eu le premier un prototype d'effacement d'objet "intelligent" mais compare ça, même 8-10ans après avec la première apparition de cette techno sous photoshop et on en rediscute.

L'objet cage de déformation, je n'en parle même pas.

Et je dis tout ça en étant un utilisateur et fervent défenseur de The Gimp (ainsi que de son nom ;)) et ne cèdant justement pas à la hype des "marques" mais Adobe CS est à un autre niveau et, putain, ça n'est en rien réducteur pour Gimp ou le libre.

Bref, faudrait voir à aller plus loin qu'une annonce slashdot qui a juste besoin de passage sur son site.

Pas la peine de me/nous insulter pour exposer tes arguments

Je suis contre le sexisme (#bouuuh) et sachant qu'il y a très probablement Ysabeau* dans le lot des moinsseurs, je ne vois pas pourquoi j'utiliserais la règle du genre masculin particulièrement.

Et l'écriture inclusive m'horripilant, je préfère jouer l'alternance.

Pour revenir sur le fond… enfin non, ça ira, je ne peux rien quant à ta vision binaire sur le proprio.

À bonnes entendeuses, salut!

* il me semble d'ailleurs qu'on est dans un cas de conflit d'intérêts.

Non groumly, tu n'y es pas, vu que le soft est proprio il est sûrement bloat et comme il est poussé par les studio et écoles, c'est probablement du copinage selon aiolos.

Gimp est pure et avec un seul gars bossant sur GEGL à son rythme et à l'envie, ça va tout déglinguer.

Maintenant, blague à part, je n'utiliserais jamais Adobe CS de mon propre chef, je connais et suis capables de trouver un moyen d'arriver à telle fin avec des outils libres MAIS j'ai l'honnêteté et surtout le bon sens de reconnaître la supériorité évidente de telle ou autre solution proprio et c'est l'absence de cette clairvoyance qui fait qu'un aiolos et ses autres copines moinsseuses font du tort au LL.

Après, pour un usage professionnel, il manque des choses à GIMP, notamment un mode CMYK

À l'heure du tout numérique, de instagram, oui c'est un frein ultime, hem.

Après si elle ne fait que du pre-press et est bloquée conceptuellement, à savoir qu'elle ne puisse pas reproduire un workflow avec une suite d'outils tier ou que ça soit antiproductif, elle devrait utiliser Adobe CS.

Ceci étant, le fait de n'être efficace qu'avec une suite particulière n'est pas péjoratif pour autant mais si l'effort requis à l'adaptation et non travestissement, n'est pas envisageable, go Adobe CS alors.

Quant au journal, inutile de le commencer avec ce pseudo côté désabusé sur le proprio.
Photoshop est et sera toujours supérieur ( efficacité, workflow ) à Gimp.

Néanmoins, en abordable et pro, la suite Affinity (proprio, mac, win, ios) à 50-60eur (frais unique) envoi du lourd.

on paie tes routes, on t'aide à avoir une voiture,…

T'es gentil mais je travaille depuis mes 17ans* et je paie mes impôts.

Tu peux très bien acheter en ville.

Non, je ne peux pas. Et les coûts directs et indirects ont été pris en compte. Sans parler de la qualité de vie.

si on remet en question ton mode de vie tu n'es pas content ?

Quel est mon mode de vie, tu sembles me connaître.

Pour un libriste, tu me sembles bien péremptoire.

Aller calme toi, sinon je vais devoir payer pour tes soins de santé. :)

• J'en ai le double.

Je sais que le sondage est volontairement limité et qu'il y a un quota d'une connerie par sondage mais ce genre de questions a une vision étroite de la réalité.

Quid de ceux qui ont vie de couple ou familiale avec des enfants qu'on essaye de faire passer pour une peine ?

La délocalisation, le dumping social est et restera le problème.
Culpabiliser les gens à posséder un bien (à usage domestique), à avoir des enfants ou de vouloir vivre hors des cages à poules de Metropolis est d'une malhonnête crasse.

Ça a l'air d'être une bonne nouvelle. Ça ne devrait pas en être une cependant : avoir accès à la doc complète du matos qu'on achète dès le jour de l'achat devrait être une évidence.

Une évidence??? Ça serait idéal certes mais que ça soit un act évident, un devoir, rien ne le dit.

Et ça mérite un moinssages de -2?

Il y a 2 features requests au sujet de cette fonctionnalité, elle mériterait de la considération de votre part.

Car le problème n'est pas la visibilité de mon message mais je ne peux pas contribuer au site et je ne doute pas que ce moinssage gratuit et systématique participe à me maintenir sous l'eau.

on peut répondre à un message du futur /o\

Tu portes bien ton pseudo :)

Il est donc possible de ré-écrire LinuxFr tout "en SAT".

Ça serait pas con, franchement.

On vote pour? ;)

https://www.blender.org/press/ubisoft-joins-blender-development-fund/

Bravo

Et pourquoi l'équipe de Nix ne fait pas beaucoup plus de travail de communication pour démontrer la supériorité de leur solution (et rappeler au monde qu'ils existent) ? C'est à eux de communiquer sur leurs travaux pour susciter de l'intérêt

Tout à fait d'accord.

Et c'est déjà mal barre d'un point de vue image car il y a déjà un fork de Nix nommé Guix.

Le forking fait parti de l'Open Source blah-blah…
Et un gestionnaire et distro de plus, ouééé \o/

Effectivement sur steam "Arch based" est 2e (woohoo) derrière "Ubuntu based".

Rien d'étonnant, les autres bossent.

On se calme les amis. :)

Personne n'est vraiment anti-flatpak ici, vous faites ce que vous voulez avec vos giga :), mais il y a des cas concrets où d'autres solutions font le boulot: partage de binaires + sandboxing sans la complexité et le côté unilatéral de flatpak.
Et malgré la bonne volonté de Renault, ça peine à convaincre.

Pour ma part, je ne comprends pas que AppImage ne soit pas plus mis en avant car dés qu'il m'a été nécessaire de recourir à un paquet de ce genre, ça a marché sans problème et sans chipotage, pré-config ou autre.

Enfin je dis ça, je viens de découvrir https://www.appimagehub.com (492 paquets) et avec des applications bien plus intéressantes et absentes des repos stable+non free de Debian, j'achète à priori (à voir le modèle d'assurance des paquets).

Alors d'un point de vu utilisateur, je vais sur un des 2 stores, je veux télécharger Olive:
- Appimagehub me fourni un .appimage de 58mo. Fichier téléchargé, droits executable donné et cliquage: Je suis prêt à dérusher et monter.

Maintenant, flatpak:
- Il me propose de télécharger un fichier org.olivevideoeditor.Olive.flatpakref. OK je reviens en arrière et je lis les instructions:
install
** flatpak install flathub org.olivevideoeditor.Olive **

error: Remote "flathub" not found

Je reviens encore en arrière, j'avais zappé le :

Make sure to follow the setup guide before installing

J'avais préalablement installé flatpak mais pas le repo.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

(déjà, le --if-not-exists prête à sourire et rappelle certaines systemderies)

Je m'execute.

error: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Flatpak system operation ConfigureRemote not allowed for user

Ah ok, je dois installer via sudo, je m'execute encore. Ici, je n'ai pas d'output pendant de longues minutes. Retour à la ligne sans output. M'okay, ça doit être terminé.

Je retente

flatpak install flathub org.olivevideoeditor.Olive

Toujours sans output mais pendant une minute cette fois et soudain, on me propose de télécharger le runtime "org.kde.Platform/x86_64/5.12 from flathub: 365 MB. Soit, faisons…

Ce qui est intéressant, c'est que je suis actuellement à l'étranger avec une connexion 10Mbits (3G) et l'écart AppImage/Flatpak est encore plus criant.

27 minutes plus tard:

org.kde.Platform/x86_64/5.12 from flathub
Receiving delta parts: 0/12 211.8 kB/s 22.2 MB/365.6 MB 27 minutes 1 seconds remaining
org.kde.Platform/x86_64/5.12 from flathub
12 delta parts, 139 loose fetched; 357048 KiB transferred in 1139 seconds
error: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Flatpak system operation Deploy not allowed for user
[/tmp ]$ org.kde.Platform/x86_64/5.12 from flathub
bash: org.kde.Platform/x86_64/5.12: No such file or directory

Quoi? Faut-il être root? je retape la commande avec sudo, et il me propose de télécharger le runtime.

C'est bon, je n'irai pas plus loin, chers lecteurs et chères lectrices.

Vous pourriez dire que c'est peut-être ma debian 9 stable mais alors, à l'eau l'argument d'universalité, mais on peut aussi rajouter les cas de multiples runtimes évoqués par Emeric et je pense qu'on reviendra tous sur sa conclusion.

Mais pourquoi pas AppImage, donc?
Je citais la faiblesse du modèle communautaire sans pognon dans un autre journal, Flatpak est supporté par Redhat et Gnome avec des moyens financiers qu'on connait et concernant Gnome, au delà de ce qu'ils produisent d'intéressant.
Bref, ce n'est pas pour rien que Red Hat et Canonical se tirent la bourre.

Suis-je un haineux, rageux, troll? Non, tant que flatpak ne force pas façon systemd pour devienir mandatory, vous êtes libres de faire ce que vous voulez avec vos gigas.

cordialement,
gabin3

ps: il n'y a pas bookworm sur appimagehub, ok, mais le premier runtime de 318MB à télécharger depuis flathub ne me tente pas plus que ça.

Sans oublier les gens qui potentiellement veulent la dernière version de Firefox ou de Libreoffice

Mauvais exemple. Mozilla et The Document Foundation fournissent des versions tar.gz (standalone) de leurs logiciels qu'il suffit de extraire.
KDEnlive et Krita offrent des versions AppImage.

En résumé, pour les gros softs, il est facile d'obtenir la version upstream voire nightly sans avoir à recourir à la compilation.

Pourtant, c'est une app qui correspond totalement à la cible de flatpak.

Pas vraiment, ce sont des applications qu'on souhaite surtout utiliser en version longue durée, pas le genre d'application à mettre à jour tous les 4 matins.
Et vu que la version standlone que propose Mozilla et The document foundation fait le boulot, Flatpak paraît bien redondant ou overkill.

Le point à améliorer serait du côté de Debian/Ubuntu ou autres qui devraient offrir un meta paquet qui ne serait qu'une sorte de wrapper (comme celui que tu as écrit) pour télécharger le tgz officiel et le rendre visible (path, etc…).

Ma position ne concernant que l'utilisateur finale, hein. Flatpak pourrait être intéressant pour du déploiement continu d'application desktop pour des devs.

Pourtant c'est bien plus simple que de se farcir RPM et DEB et autres.

Vraiment pas plus simple qu'un Appimage.

Si tu es GNOME centrique, oui, tu pourras tâter de la dernière version de bijiben qui permet de rechercher dans tes notes mais à part ça, en terme de logiciels pas plus que dans les repo de ma distros.
Si encore, t'avais les trucs un peu "rares" comme bookworm ou autres projet sur github qui ne sont pas nécessairement accèssible sur une Debian stable/Ubuntu LTS ou galère à compiler mais ce n'est pas le cas.

Il y aussi l'absence de repo/store de référence et plutôt vides.

AppImage ne nécessite aucuns tool annexe, les paquets sont en dessous des 200mo et fonctionnent partout.
J'ai pu, grâce à ce format, tester les dernières version de Krita, Kdenlive ou compléter un atelier de dev application mobile hybride avec appium (distribué sous forme d'AppImage). Et ce, sans installer 3 tonnes de données.

Je garde les repo de ma distro stable comme source principale et j'ai recours à Appimage si je ne sais pas compiler l'application de manière raisonnable ou pour la partager. Appimage résout aussi le partage d'application propriétaire pour ceux que ça intéresse.

Alors Flatpak apporte le sandboxing, pourtant firejail existait déjà. Et encore une fois, intérêt majeure pour les applis hors depôts officiels et ou proprio.

Mais et surtout, il n'est en rien facile pour l'utilisateur finale.

Permettre à d'autres distributions d'avoir la fraîcheur applicative de Fedora via les Flatpak, dont notamment CentOS (mais valable pour Ubuntu, Debian, etc.) ;

Cette "fraîcheur" qu'avence les rolling release et autre Fedora me fait doucement rire.
Est-ce la mort d'avoir libjpeg-1.22 au lieu de libjpeg-1.30?
Ou c'est pour avoir l'illusion d'avancement du projet GNOME? J'ai personnellement utilisé les versions de GNOME fournis sur les stables et c'était stable au point d'en oublier cette élément et me concentrer sur mes tâches.

Est-ce vraiment si bien d'avoir un noyau 5.x* en avance qui corrompt un SSD?
Ma version ESR de firefox n'a pas été impactée par le problème de certificats des addons et le net n'est pas devenu incompatible en 2 versions.

Bref, Les distros stables et LTS fournissent ce qui est important, une base stable et des mises à de sécurité et on peut toujours ajouter des repos/ppa spécifiques ou utiliser de l'AppImage.

mes 2 centimes

• Qu'on soit clair, il est tout à fait possible d'avoir un noyau aligné sur upstream sur des distros stables.

Cette nouvelle version de Debian GNU/Linux contient plus de 51 000 paquets, dont 15 000 nouveaux. Par ailleurs, 6 000 paquets ont été supprimés depuis Stretch.

Ça fait peur tout de même, 51 000 paquets! Qui audite ça?
J'imagine que ce nombre inclus le même logiciel sur les différentes architectures, donc nombre à diviser par 10, ce qui rend le bazard moins flippant mais tout de même.

Il doit être illusioire de vouloir s'assurer de tout à 100% en amont de l'empaquetage du dit logiciel, non?

Bah oui, c'est ça l'intérêt de ce renommage, il y a un lien physique entre l'interface et le matériel. Alors que sinon, au redémarrage,

De souvenir, c'était typiquement un problème de CentOS/Redhat, quand tu ajoutais une interface réseau après une installation.

Après, généralement, quand je provisionne une machine ou une VM, je m'assure toujours que telle MAC soit liée à telle interface via une règle qui va bien.

Et au moins, je peux prétendre à un nommage consistant contrairement à ce que la doc redhat prétend.

Avoir quelque chose comme enp0s3f12, je ne trouve pas cela très parlant. Or, il se trouve que l'adresse MAC est la première donnée tangible que je peux avoir avant même d'installer l'OS, et du coup faire le lien.

On peut toujours créer des alias ou des interfaces virtuelles mais ça allourdi la tâche et surtout, ça n'apporte rien par rapport à l'adresse MAC, mon opinion.

La plupart des distributions y sont passés il y a longtemps sans soucis. Fedora l'a fait même pour Fedora 15, en 2011.

Je n'utilise pas Fedora sur server et encore moins en production.

Les distrib adoptent ce qui leur paraissent le meilleur. Et bien souvent RH a contribué très fortement a ces technos

Quelque part ça montre la fragilité du modèle opensource communautaire. Les distros le feraient certes parce que cela leur paraîtrait le meilleur mais aussi, je pense, car il s'agit de tâche énorme que le modèle économique communautaire dans le cas de GNU/Linux, inexistant donc, ne permet pas. Bon, ça serait majoritairement vrai pour un Xorg/Wayland mais normalement pas pour un système d'init (ce que n'est pas systemd).

Bref, ce genre de projet d'ingénierie "dur", c'est autre chose que de faire un fork de Debian avec un wallpaper brandé et quelques paquets compilés avec -O4.

Qui apprécie vraiment ce changement? Je dis "apprécier" non pas dans le sens d'aimer mais dans le sens de reconnaître sa valeur ajoutée, d'y voir une amélioriation.

Basculant entre plusieurs machines physiques, dont serveurs à multiple eths, tout le temps et tous les jours, ça ne m'a toujours pas sauté aux yeux si ce n'est le côté ennuyant et imprévisible.

Et si c'est pour les machines virtuelles, je ne vois pas non plus l'intérêt.

Pouvez-vous expliquer le raisonnement derrière, svp?

Notez qu'il a y a(vait) un paramètre noyau pour activer l'ancien comportement mais celui-ci ne marche que pour l'ethernet.

À défaut de rendre visible les moinsseurs, ton approche a le mérite d'être constructive.

Je subis des moinssages étranges même quand j'apporte une aide dans les forums.

Que les moinsseurs offrent la solution.