Albert_ a écrit 6115 commentaires

Sauf que tu passes par un logiciel intermédiaire qui effectue une conversion donc ce que tu dis est vrai mais n'apporte aucune information sur le format interne de Google doc.

Un des petit problème est que personne n'a pondu un logiciel respectant a la fois la norme et étant compatible avec microsoft office. Même pas Microsoft…

Ah d'accord et ceux qui utilise un ordi qu'ils n'ont pas installés, ils n'utilisent pas elur ordi?

PS: vu le nombre de bug report que j'ai rempli et qui furent accepte comme tel par les devs de arch ils sont un chouilla moins fermes que ce que tu suggeres!

Euh si il existe des installeurs:

• pour utilisateur experimenté: arch
• pour ceux qui prefere la gui: antergos (il va etre remplacer) ou manjaro

J'ai fait des installations a la arch (a la mano) mais je dois avouer que les installations à la antergos c'est aussi bien pratique, oui oui je sais je suis feignant, mais cela marche nickel maintenant.

La doc python utilise cela aussi depuis pas mal d'année avec Sphinx.

Qui lui utilise reStructuredText et Markdown

Et je n'ai encore jamais téléchargé de paquets tiers avec des binaires statiques, toujours des trucs bien faits.

Peut etre mais bon dans d'autre domaine que tes PME, il existe des logiciels qui ne sont deployes que de facon statique et qui sont bien fait (parfois) meme si proprio. Par exemple je peux citer:

• Matlab
• Ansys
• Abaqus
• Mathematica
• Maple
• comsol
• Les compilateurs Intel
• …

Et je te met au defi de trouver des versions fournis de facon non statique!

Apres si l'on parle de libreoffice ou de module python en effet cela est meme fournit par la majorite des distribs directement sans passer par des bidouilles alien et sinon il 'suffit' de recompiler le logiciel voir mieux de creer ton paquet pour ta distrib. Quand tu as les sources cela est faisable quand tu ne les as pas ceci est une autre paire de manche.

Et hop une petite attaque ad hominem…

Si tu ne veux pas comprendre que donner comme conseil de prendre n'importe quel paquet et d'utiliser alien pour le 'convertir' dans ton format preferé puis de forcer a la mano une installation a un nouvel utilisateur linux est une très très mauvaise idee, je ne peux pas grand chose.

Ce genre d'installation met très très vite le bazar dans une distrib même quand cela fonctionne … en aparence. Nous sommes plusieurs à le dire…

Exemple de probleme possible https://www.archlinux.org/news/libutf8proc211-3-update-requires-manual-intervention/

Peux être devrais tu expliquer a archlinux ta solution magique?

La compatibilité est assez bonne entre Ubuntu et Debian

Mais bien sur et la marmotte… Enfin tu as pris tes précautions avec l'utilisation du mot assez. Déjà qu'entre deux versions d'une meme distribs cela ne fonctionne pas pour des raisons de compatibilites de versions de librairies partagées alors entre deux distribs différentes c'est à peu près impossible (cela peut arriver) et c'est extremement trompeur de prétendre l'inverse.

Il y a aussi le cas des logiciels Python ou Perl qui s'installent souvent sans problème.

Pour Perl je ne sais pas mais avec Python je pense que tu peux aller te brosser pour avoir une compatibilité binaire entre distrib et un module tel que numpy!

Par ailleurs depuis très longtemps Alien permet la conversion entre les formats de paquets binaires. Je m'en sers de temps à autre et ça fonctionne pas mal, moyennant quelques bidouilles : je crée par exemple des paquets fictifs et vides pour remédier aux dépendances dont les noms et versions ne correspondent pas.

Encore une fois oui cela peut fonctionner … sur des trucs compilés statiquement sinon les chances que cela fonctionne directement sont proche de zero.

Beaucoup d'éditeurs fournissent un deb pour ubuntu/debian et un rpm pour RHEL/SLES.
Preuve qu'un paquet n'est pas nécessairement limité à une unique distribution.

J'ai oublier de préciser que les éditeurs qui font cela fournissent des paquets compilé tout en statique et que en gros le paquet n'est la que pour l'installation et etre integre plus ou moins proprement dans le systeme d'installation.
Ils pourraient fournir un tar.gz a décompréssé pour les 4 distribs et cela fonctionnerait directement aussi (modulo un script de demarrage definissant toutes les variables bien comme il faut).

Par contre, comme dit auparavant, prendre un paquet fedora de chez fedora il y a peu pres zero chance que cela fonctionne directement ou par miracle si les libs partagées sont les exactement les memes (et c'est un probleme parmis d'autre)…

Maintenant on va peut etre considerer mes messages comme n'etant pas totalement debile. Merci.

Une astuce, si comme moi vous êtes coincé en mode clone en HDMI et que la conf d'Affichage vous montre qu'un seul écran, en fait les 2 écrans sont superposées, il suffit de faire un drag dessus.

Sous KDE il existe en encore mieux maintenant avec un plasmoid pour gerer cela de facon simple: "display configuration". Perso je l'ai mis toujours visible dans le "system tray"

Je repondais à cela:

Ça utilise dnf donc j'ai à ma disposition tous les paquets fedora par défaut ?

Vas tu dire que un paquet Fedora a 100% de chance d'etre installable et utilisable par Mageia?

Le format etant un format commun RPM

Si oui je pense que tu devrais faire l'experience … pour rigoler. Si les paquets ne sont pas fournis avec des libs statiques cela peut (ou pas) fonctionner…

tiens c'est amusant une personne a considere que le post precedent qui repondait a une question de celui au dessus n'etait pas pertinnent.

Pourrais t'il s'expliquer et donc justifier que installer des paquets d'une autre distrib fonctionnera sans probleme sur sa distrib.

Je suis tres curieux d'entendre cela et donc qu'il explique que flatpak et qautre truc equivalent sont absolument inutile…

Bien sur que non, Gnome a pour philosophie de ne jamais reprendre et participer au code KDE et de re-ecrire le code meme quand KDE a fait le boulot pour séparer de libs et fournir un client gnome-shell comme c'est le cas pour kdeconnect…

Donc ils ont tout re-écrit et ne mutualisent pas les efforts…

Ne jamais melanger les paquets provenant de distribs différentes. Les deb de debian ne sont pas plus compatibles avec les ubuntu que les rpm de fedora avec ceux de mageia.

Pour moi le probleme n'a pas été le download mais l'installation. Bon on va etre honnete, le lendemain quand nous sommes revenus au boulot et que l'installation en etait encore a 95% puis 96% 1h plus tard. Nous en avons eu assez et nous avons fait ce qu'il etait dit de ne pas faire… Eteindre et redemarre avec la joie de devoir réparer le grub. Le soir nous avons relance la procedure et c'est alle beaucoup plus vite et en 30mn c'etait fini par contre nous n'avons absolument aucine idee de ce que l'arret a bien pu mettre en l'air (non non le grub c'est "normal" qu'il ait ete detruit…) mais comme il ne sert pas a grand chose le windows ce n'est pas trop grave :)

J'ai du upgrader un pc du boulot et le passer de 1803 vers la 1904 le systeme informant que la version 1803 ne serait plus maintenu. "En theorie" passer par l'update aurait du fonctionner mais en fait non et il a fallu recuperer un executable sur le site de Microsoft.
Par la suite, la mise a jour s'est déroule sur … plus de 18h (me demandait pas pourquoi) et le bonheur de voir le grub écrasé (comme par hasard).
Naturellement par la suite il a aussi fallu faire l'update des drivers.

Toujours aussi amusant les updates de windows :)

Exactement pour avoir "rencontré" un crétin qui s'amuse à faire cela c'est plus pour montrer "que c'est un vrai un pur un dur"… alors que dans les fait c'est juste un script kiddies totalement nul!

C'est cool je savais que les anti-sciences etaient en vogue mais je ne croyais pas que les adeptes de l'utilisation de formules mathematiques volontairement fausse se balader sur ce site.

C'est beau comme un camion.

Mais si cela te convient tant mieux pour toi. Ne viens pas pleurer quand Microsoft decidera de changer le format qu'il est le seul a controler.

1. Comme il est impossible d'implementer la norme correctement (meme Microsoft n'y arrive pas en dehors du client lourd historique), ce que tu dis est faux.

2. Le fait d'utiliser uniquement ce format promeut le fait de ne pas travailler avec les autres mais d'imposer de force des trucs pourris et mathématiquement faux (encore une fois certaines formules statistiques sont mathématiquement fausse dans la definition du format et gardes fausse pour la seule et unique raison de garder la "compatibilite" avec le client lourd Microsoft Office)

Sauf que la "petite" différence vient du fait que LibreOffice implémente une norme décidé avec plusieurs acteurs du marché et dont le projet n'a donc ni les tenant ni les aboutissant.

Microsoft a pondu Microsoft OOXML de tel sorte a que ce truc ne correspondent qu'a une seule et unique chose: le format de Microsoft Office 2013 et précedent.

Il n'y a eu strictement aucune interaction avec le moindre autre acteur du marche meme pas interne sur le sujet.

Microsoft OOXML n'est pas une norme implémentable par qui que ce soit d'autre sauf a reproduire les bugs specifique non documente de Microsoft Office 2013 et précédent y compris les erreurs mathématiques dans les formules de statistiques!

1. une seule compagnie l'a produite et a refuse toute correction de la "norme" lors du processus de "normalisation"!
2. il y a des blobs binaires qui peuvent etre mis dedans

mais bon je dois avoir une autre notion de la notion de standard ouvert!

Ok nous sommes d'accord donc mais cela veut dire que les scripts bash des power user seront bien souvent incompatible et inversement… et donc ils installeront bash!

Plonge toi dans les archives de dlfp avant d'insulter.

Les arguments ont été ressassé au moment de la 'normalisation'.

Et au dessus j'ai parlé des superbes formules mathématiquement fausse du format MS ooxml mais bon ca c'est visiblement pas un argument pour toi.