Pinaraf a écrit 3682 commentaires

Dans ma boite quand on utilise le cloud c'est par commodité (dispo immédiate, scaling à la volée, possibilité d'arrêter à l'instantané), pas pour le prix car à chaque fois qu'on compare avec une solution on-prem gérée par nous-même les solutions azure,aws,google sont plus chères.

Je vois mal chaque établissement scolaire avoir sa salle serveurs maintenue en état de marche. En france, les collèges sont financés par les départements, les écoles primaires par les communes (en tout cas sur la métropole lilloise). Tu penses qu'une école primaire peut avoir sa salle serveurs ?

Si le ministère centralisait, évidemment, une solution moins onéreuse serait possible. Mais il faut accepter d'aligner un budget et de payer du personnel dans le public… c'est-à-dire des fonctionnaires ! Quelle horreur ! (Souvenez-vous de 2017 et du concours sur le nombre de postes de fonctionnaires supprimés par chaque candidat…)

Tu mentionnes le prix du support pour une des solutions. Combien de fois crois-tu qu'une école crée des tickets pour du support office en 1 année?

0 fois, pourquoi ?

Il y a vraiment besoin de support pour apprendre à des grosses les bases du traitement de texte ?

Si la solution tombe en panne (ce qui est plus impactant à partir du moment où c'est distribué avec une partie serveur), le faire sans support serait un comportement amateur, littéralement : pour un usage amateur, pas de problème, mais là le client (l'école donc, pas le gamin) est professionnel et ne peut pas se permettre d'y aller sans filets…

Je comprend la remarque du coût, mais présenté comme cela, on a l'impression que Crosoft cest gratuit.

Je pensais avoir été assez clair, navré : Microsoft bénéficie, comme les autres opérateurs de ce type, d'économies d'échelle. Ils sont tellement gros qu'ils sont moins chers. Et oui, 20€ par trimestre par élève, c'est vraiment pas cher. Si on plaçait la décision au niveau d'un collège, mettons de 500 élèves, nous arrivons à 10000€ par trimestre, 40000€ par an. C'est, dans le budget des départements (qui paient les collèges), une note de bas de page.
Imaginons qu'il faille mettre du LibreOffice à la place.
Tout d'abord, il faut trouver un fournisseur/prestataire.
Bon.

On va prendre la liste des hébergeurs donnés par Collabora, on va supposer qu'ils sont de confiance, et prenons du «made in france». On a deux choix. Le premier a une offre à 4€ par mois en mode basique, «support communautaire», et 6€ par moi en mode pro, mais «support communautaire» également. Inacceptable pour une collectivité (l'alternative est sur devis, je n'ose demander). Le second fourni uniquement une offre intégrée pour entreprises incluant Collabora Online, donc hors course.

Bon, alors prenons un Allemand. EGroupware, 1000€ par an + 5€ par utilisateur par an. C'est… pas cher ? Ha, le support n'est pas inclus, à 120€ par heure. Mais revenons sur le pas cher, parce que quand même. À ce prix, vu ce que bouffe LibreOffice Online en ressources, il y a un loup. LibreOffice Online implique actuellement d'avoir LibreOffice qui tourne en arrière plan, dans le style des frameworks RIA d'une grande époque (souvenirs…). Ce qui vient avec une certaine consommation de CPU, de RAM et de bande passante. Or, Nextcloud recommande pour Collabora Online un maximum de 10 utilisateurs par fil CPU, et au moins 100 Kbit/seconde (!) et 100 Mb de RAM par utilisateur. Si il y a 150 élèves dans l'école, l'instance de l'école a besoin de 15 Gb de RAM, 15 Mbit/s et 15 fils d'exécution CPU. Sur un budget de 1750€ par an, chez les hébergeurs les moins chers on va déjà consommer quasiment tout le budget avec les machines (hetzner, 771€ par an, et pour du matériel grand public, × 2 vu qu'il y a deux centres d'hébergement dans l'offre). Je suis donc très très surpris qu'ils arrivent à rentrer dans leurs frais.

Hosting.de, un concurrent, est à 4€ par utilisateur par mois. C'est déjà plus réaliste. Mais à 50 utilisateurs maximum. Soit 5 cœurs CPU, 500 Mb de RAM… Un petit serveur par instance peut-être ?

C'est là que l'on vois la puissance du marketing, on en oublie que Microsoft a aussi une infra à payer (et donc des admin sys).

Microsoft, Google et Amazon ont franchi tous les paliers en volume. Ils n'ont plus des fermes de serveurs, ils ont des fermes de serveurs Microsoft/Google/Amazon. Avec par exemple :
- une alimentation par baie, voire par salle qui sait, en courant continu, plutôt qu'avoir un transformateur par machine (plus efficace, moins cher, mais c'est du matériel custom, donc un gros coût R&D et un volume minimal requis pour amortir),
- leurs propres CPUs qu'ils font fondre par TSMC ou éguivalent. Parce que c'est moins cher de prendre des licences ARM et de faire fondre les processeurs, vu leurs volumes, que d'acheter de l'Intel/AMD (et dépendre des délais de production de ces derniers),
- des bâtiments possiblement hyper avancés pour diminuer le coût en refroidissement (je ne suis plus au fait des avancées sur ce sujet, d'où le conditionnel)

Donc oui, Microsoft, Amazon, Google ont réussi à compresser à mort leurs coûts. Et quand il s'agit derrière de revendre du Microsoft Office, ils n'ont pas à faire de gros efforts pour avoir des prix intéressants.
Le prix ne doit pas être l'argument majeur pour les attaquer, sinon c'est jouer leur jeu et perdre d'avance.
Il faut tenter d'argumenter sur les retombées locales d'employer plutôt que de sous-traiter à l'étranger, le patriotisme économique, le respect de la vie privée… Mais en fin de compte, depuis quand un élu est-il jugé sur ça plutôt que sur la tenue des dépenses ?

PS : c'est cadeau, deux arguments massue :
1) les appels d'offre : il faut être capable de répondre à des appels d'offre en français, et de donner des réponses convaincantes. C'est bien plus compliqué qu'il n'y parait, seuls des gros peuvent y arriver (passer des mois avant d'avoir un brouzouf… c'est chaud pour une entreprise lambda)…
2) la force du nom. Comme à la grande époque où on ne pouvait pas nous reprocher d'avoir pris de l'IBM, on ne peut pas reprocher à un décideur d'avoir pris du Microsoft : si ça tombe en panne et que c'est du Microsoft, on ne lui reprochera pas, alors que si ça tombe en panne et que c'est du Tartempion©, on lui reprochera…

Attention quand même avant de défendre les outils de développement de macro intégrés à LibreOffice. Ils sont à la ramasse par rapport à Microsoft Office (au point qu'il était même envisagé d'en retirer notamment l'enregistreur de macros à l'époque d'OpenOffice.org, si ma mémoire est bonne).

1) L'enregistreur de macros, outil parfait pour savoir «comment je fais X avec l'API de mon logiciel», est désastreux puisqu'il ne fait pas d'appels directs mais passe à la place par une API spécifique d'IPC difficile à lire. De plus, il rate une grande partie des événements.

Exemple : voici la macro pour passer en paysage la page dans Writer

sub test_macro_page
rem ----------------------------------------------------------------------
rem define variables
dim document   as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

rem ----------------------------------------------------------------------
dispatcher.executeDispatch(document, ".uno:PageDialog", "", 0, Array())


end sub

Indice : ben ça ne fait qu'ouvrir la fenêtre de style de page…

2) L'outil a de la coloration syntaxique… Oui, mais il n'a que ça. Pas de complétion de code, l'éditeur de dialogue est bien plus fastidieux à manipuler que dans VBA (pour la faire courte : VBA associe un objet au dialogue, et fait donc correspondre aux événements du dialogue une méthode privée dans l'objet)…

3) Jusqu'à il y a très très peu de temps (la version 7.2 d'août) il fallait l'indispensable extension XRay pour pouvoir explorer depuis l'outil de développement les méthodes d'un objet.

Ça existe dans la version en ligne de libreoffice, Collabora Online.

Et ça pose trois problèmes :
0) A priori la collaboration est possible sur les versions bureau de Word/Excel/…
1) LibreOffice Online (je ne sais pas si c'est différent de la version Collabora) est inutilisable si tu as de la latence. (Source : témoignage des sysadmin du projet KDE sur le choix entre LibreOffice Online et OnlyOffice pour un outil interne)
2) L'hébergement. Collabora Online est proposé «on-premise» uniquement. Du coup, outre les 17€ par utilisateur par an, il faut ajouter le prix d'un hébergement. Et d'un admin sys pour cet hébergement si c'est pas un prestataire de services clé en main.

Le cloud est un concurrent terrible puisque, si on est face à des gestionnaires qui ne regardent que le prix (et qui détestent payer des salaires), ces offres sont imbattables : elles ont de telles économies d'échelle qu'il est inenvisageable d'atteindre leur coût.

Je parlais plutôt de la collaboration en temps réel à plusieurs sur le même document, ce qui dans le milieu scolaire (mais pas en primaire à ma connaissance) est un plus non négligeable. Pour ma part en école d'ingé mes camarades étaient ravis que je sorte Gobby pour certains TPs/projets…

Je me dis que sur une utilisation experte (qui n'est pas la mienne) il y a peut-être des fonctionnalités présentes sur l'un mais pas sur l'autre. Mais dans le cadre d'une utilisation scolaire, quelle fonctionnalités si importantes sont présente sur Office et pas sur LibreOffice ?

Les fonctions de collaboration sont, de ce que j'ai compris, un cran meilleures que celles de LibreOffice, avec en prime une partie web (Office 365) qui tient bien la route et est déployée. Bon, qui tient la route… c'est ce que les gens croient, parce qu'un traitement de texte qui permet pas d'insérer une table des matières, c'est un gros foutage de gueule…

Effectivement, MuPDF affiche bien ce PDF, merci. Par contre, il ne sait pas imprimer ?

Ha en effet, ce n'est pas dans ses fonctionnalités, navré.

Par contre, le lecteur de Firefox l'affiche bien, mais à l'impression c'est aussi illisible

Le système d'impression utilise nativement du PDF. Du coup il est possible que Firefox fasse juste passe-plats pour imprimer le document, qui du coup est rendu derrière par le système d'impression ou l'imprimante directement.
Firefox n'a pas dans ses options la même option qu'a Okular lors de l'impression, à savoir en anglais «Force rasterization», qui convertit le PDF en images pour l'imprimante, contournant moultes bugs dans cette dernière du coup (mon record c'est une imprimante qui a imprimé une stack trace au milieu du document).

En lecteur alternatif, je recommande vivement mupdf (que je n'avais jamais essayé avant d'écrire ce journal) qui a un moteur de rendu à part entière.

Si tu veux tu peux m'envoyer en privé le document pour que je vois pourquoi il s'affiche mal (mais s'agissant de données de santé je doute que ce soit conseillé), mon adresse mail est la même que mon adresse XMPP… Sinon les astuces de ce journal ou des commentaires devraient aider.

La notion de "assez récente" est très relative. Cela fait 8 ans que Firefox a son afficheur PDF intégré, depuis la version 19…
Tu ne le trouveras pas par un locate, il est planqué dans un fichier de ressources.

$ unzip -l /usr/lib/firefox-esr/browser/omni.ja | grep pdf.js
284283 2010-01-01 00:00 chrome/pdfjs/content/build/pdf.js

Pourquoi ? J'ai tout bien lu ce matin, et n'ai pas capté comment FF s'y prend.

Firefox a son afficheur, pdf.js, qui calcule bien que la police demandée est en chasse fixe, et assigne donc dans les propriétés CSS un font-family: monospace.

Vous avez tout à fait raison, monsieur le premier ministre.

???????

J'allais dire juste «vous avez tout à fait raison», et forcément j'ai pas pu m'empêcher, il a fallu que je complète la citation… (cette phrase est issue du débat des deux tours de la présidentielle de 88)

Merci pour le lien vers le fichier, mais sans doute qu'une image du texte défectueux aurait été utile car chez moi (vieux Linux Debian Wheezy, vieux FF) le MA de MADAME s'affiche correctement, tout comme le reste.

Vous avez tout à fait raison, monsieur le premier ministre.

Sur Firefox en tout cas, c'est normal que tout s'affiche bien.
Sur Okular, ça donne ça :

Popple tourne sous Linux, Windows, MacOS. Il peut avoir des dépendances, ce n'est pas lié. Par défaut sous Debian en tout cas, poppler ne dépend pas spécifiquement d'un ensemble de polices. poppler-data suggère d'installer un ensemble de polices pour les langues asiatiques, mais c'est tout. Après, via les dépendances à fontconfig il va dépendre d'un ensemble de polices, mais c'est au choix de la distribution. fontconfig ne m'oblige pas à avoir de police de symboles par exemple.

Et Helvetica n'est pas implémentée par défaut sur Windows. Effectivement, Arial est censée la remplacer, mais elle est moins bien dessinée.
Pour Linux, les polices de substitution doivent être la série Liberation : Mono, Sans et Serif ainsi qu'OpenSymbol

L'OS n'est pas l'afficheur de PDF. Sous Windows, Acrobat Reader embarque un panel de police, par exemple AdobePiStd qui remplace la ZapgDingbats. Mupdf embarque les Nimbus Sans en remplacement d'Helvetica. Nimbus Sans qui, au passage, ne gère pas que les langues occidentales, fort heureusement.
C'est un choix d'implémentation de poppler que de ne pas embarquer de polices, ce qui peut poser problème du coup.

Bien vu, merci bien !

Par exemple la police wingdings embarquée dans le document du journal est réduite à seulement 3 caractères. Décompressée, la police ne fait donc plus que 6164 octets en TrueType (ce qui me semble encore beaucoup, mais je ne connais pas assez le format TrueType pour juger). À titre de comparaison, la police NotoSansSymbols, du même style que la wingdings, pèse 252 ko.

Oui le drapeau est supposé indiquer le type de police. Mais je pense que trop de générateurs de PDF ont fait l'erreur et que pour mieux afficher tous les documents qui ont été générés par le passé, il n'y a plus guère de choix.

Par contre le remplacement des deux n'est nécessaire que à cause du bug de fontconfig. Poppler prend bien en compte le drapeau s'il est présent, mais le nom de police faisait partir en vrille fontconfig sur sa configuration par défaut.

Y-a-t-il un autre intérêt en dehors de compenser pour un flag incorrect ?

Alors la vérification des tailles, non, ça n'a pas d'intérêt. Mais la taille sert en cas de récupération de police de la même famille que la police demandée, mais pas nécessairement de la même taille précisément.

Au passage, il me semble qu'il est possible d'embarquer les polices dans le PDF. Perso je préfère ça, justement pour éviter les surprises en changeant d'appareil.

Tout à fait, je le mentionne avec la police Wingdings qui est embarquée dans le document. Mais pour les polices que «tout le monde a», il peut être légitime de ne pas les inclure. C'est le cas notamment de Helvetica et ses clones. Ça permet d'avoir un PDF un peu moins volumineux, même si ça sert moins aujourd'hui…

Les PDFs sont conçus pour avoir des polices manquantes. Quand la police manque, c'est une police «compatible» qui sera choisie, sauf que compatible est un vaste mot. Pour être donc plus proche du rendu original, les largeurs des caractères sont précisées. Maintenant, spécifier des largeurs différentes sur une police à chasse fixe… je me demande ce que ça ferait…

Avec une compilation basée sur cmake l'équivalent est cmake -LH

Je préfère ccmake pour ça, l'interface curses est plus sympa.

Plutôt que d'essayer jusqu'à ce que ça marche (et rater d'éventuelles dépendances optionnelles), mieux vaut commencer par un apt build-dep geany

utiilisateur => utilisateur

D'après Nate Graham (très connu dans la communauté KDE, et qui a travaillé avec Valve pour le Steam Deck), et si j'ai bien compris, le bureau est disponible quand on branche clavier/souris/écran sur le Steam Deck et qu'on le transforme donc en véritable ordinateur.
https://pointieststick.com/2021/07/16/this-week-in-kde-kde-powered-steamdeck-revealed/

Toute blague à part, l'article de the register est faux également, et c'est ce qui m'inquiète le plus. Plus de gens lisent the register que phoronix ou lwn (où en plus il faut un autre niveau technique) et donc plus de gens penseront que «a lot of 40-pin ribbon cables [are made] redundant unless users adopt the libata code that remains in the kernel.» et «Those still wedded to storage tech that uses those cables were given around two years’ warning of IDE’s demise in the kernel.»
C'est complètement faux, y'a eu deux ans d'avertissement pour les personnes sur archis exotiques pour que les derniers pilotes soient portés. Maintenant qu'ils le sont, c'est dégagé, mais du coup ça va marcher presque tout seul (faudra juste faire gaffe au renommage hda => sda). Aucun «user» ne doit faire de changement, à part sur le fstab et la conf grub, mais de toute façon sur m68k t'es tout seul ou presque :)

Et dire qu'un "gros" argument qu'on me sort souvent contre les OS non libres est que les OS non libres "font de l’obsolescence programmée"… "Prend Linux, au moins ton vieux matos est toujours supporté avec lui", Que fait la police?

La police dit que ce journal titre de lien c'est de la merde :)

Linux 5.14 a supprimé le support «legacy» de l'IDE, celui qui nommait les disques en HDA, HDB, HDC, et qui n'était plus utilisé que sur m68k.
L'IDE est évidemment toujours géré, ils ont juste porté les derniers pilotes. Cf. https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.14-Legacy-IDE-Dropped