Mon ressenti sur l'utilisation des exceptions, après avoir travaillé sur des projets en C et en C++ avec et sans exceptions, c'est plutôt l'inverse.
Sans exceptions, on se retrouve à écrire au moins 3 lignes de code de gestion d'erreur par ligne de code "utile":
Code utile:
faire_un_truc();
Avec gestion d'erreurs:
result = faire_un_truc();
if(result) {
libérer_les_resources();
return;
}
Si on a une fonction un peu plus longue qui alloue plusieurs resources, ça devient très vite le bazar de s'assurer que on a bien libéré toutes les ressources allouées.
Alors que avec les exceptions et la RAII en C++, ça se fait tout seul: tous les objets alloués sur la pile sont automatiquement libérés lorsqu'on quitte la fonction.
Bien sûr, pour que ça marche bien, il faut que toutes les resources soient liées à l'existence d'un objet sur la pile. Ce qui peut être compliqué si on en a pas l'habitude ou si le projet (ou les bibliothècues utilisées, ou l'OS ciblé) n'a pas été pensé pour.
Tout ça pour dire qu'il existe aujourd'hui un réel flou juridique concernant ces technologies. Et c'est pas les développeurs ni des entreprises privées qui le résolveront. Ce seront des avocats/juristes/gouvernements à coup de nouvelles licences et de nouvelles lois.
Je ne pense pas que la solution ça soit une nouvelle licence ou une nouvelle loi. C'est effectivement une lecture "juridique" du texte de la licence existante.
Le texte de la licence MIT a justement l'avantage d'être extrêmement clair et simple. Il donne le droit de faire tout ce qu'on veut à condition de reproduire le texte de la licence et la notice de copyright.
Alors on peut prendre un.e juriste et lui demander de faire dire à la licence le contraire de ce qui est écrit, mais comme la licence est simple, courte et claire, son travail va être compliqué. Oui, iel pourra tenter des trucs. Mais iel va avoir du mal à trouver quelque chose.
Par exemple, la question "est-ce que github a obtenu une copie du code?" ça va être difficile de dire que non.
À la question "est-ce que Copilot reproduit la licence avec le code quand il le réutilise?" la réponse est clairement non.
Et comme je le disais, la question qui se pose est plutôt "jusqu'où on peut aller si on ne veut pas respecter les termes de la licence?" (dans ce cas, reproduire la licence et la notice de copyright)?
La réponse est là aussi assez simple: c'est le droit d'auteur qui s'applique. Il donne quelques droits "par défaut", j'en ai cité quelques uns. Et c'est plutôt là que le débat va se situer: est-ce que les droits donnés par défaut par le droit d'auteur sont suffisants pour l'utilisation que Github a fait du code? Là, on arrive dans une question plus pointue, et effectivement, comme je ne suis pas juriste de formation, je ne vais pas m'engager dans une réponse à ce niveau là parce que ça dépasse mes compétences. Mais il n'est pas difficile de trouver des informations sur ces droits si on veut se pencher sur la question.
Mais sur la lecture d'une licence et son application dans les cas classiques, je pense que tous les développeurs devraient au moins être sensibilisés au sujet. Ça évite de faire n'importe quoi. Un peu de la même façon qu'on demande aux gens de connaître un minimum le code de la route avant de conduire une voiture, pas tous les articles par cœur, mais de quoi se débrouiller au quotidien dans les situations courantes.
Ces licences couvrent la redistribution et la modification du code. Elles ne couvrent pas son usage dans une analyse automatique.
Voici ce que dit la license:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so
(avec une clause d'attribution ensuite).
Donc la permission qui est donnée est: "to deal in the Software without restriction", avec quelques exemples non exhaustifs ("including witohut limitation"), dont la redistribution.
Il n'y a pas du tout de limitation à la redistribution ou à la modification du code. Si tu as reçu une copie de ce code (trouvé sur github ou il a été volontairement publié par exemple), tu as le droit de faire ce que tu veux avec sans restriction, tant que tu cites le nom de l'auteur.
Si tu ne cites pas le nom de l'auteur tu as les droits donnés par:
- Les conditions d'utilisations de github (droit pour n'importe qui de forker le dépôt par exemple, ce qui ne fait pas vraiment de copie et donc ne pose pas de problème de droit d'auteur en soi)
- La loi sur le droit d'auteur, qui par défaut interdit tout, sauf accord de l'auteur, et des exceptions pour les courtes citations, parodies, etc (variables selon les pays).
A priori la loi sur le droit d'auteur n'a pas de clause spéciale pour l'analyse automatique. Les conditions d'utilisation de Github, peut-être. Mais si des gens ont déposé sur Github du code dont ils ne sont pas détenteur du copyright, sans l'autorisation dudit détenteur, je vois mal comment les conditions d'utilisations de Github pourraient alors outrepasser la license.
Dans le pire des cas on va en détruire un (Haiku Jam) pour le remplacer par un autre (Ham). Dans le meilleur des cas, on va en détruire deux (Haiku Jam et Boost Jam) pour les remplacer tous les deux par Ham.
En fait tout cela est assez neutre puisqu'on ne crée pas de nouveaux fichiers de build, on crée un nouvel outil qui utilise les fichiers déjà existants. Qui sont d'ailleurs loin d'être parfaits dans Jam, mais je pense que ça va permettre de travailler sur des aspects intéressants du problème (intégration dans les IDE, meilleur suivi des dépendances, rapidité de parsing des fichiers) en sautant les étapes "réinvention de la roue" de la conception d'un nouveau langage de build.
Peut-être que d'autres outils devraient faire ça? Est-ce qu'on adopterait plus rapidement un outil qui fait "tout comme CMake mais deux fois plus vite" qu'un outil "il faut réécrire tous les scripts de build mais ça va trois fois plus vite"?
Utiliser les outils existants (en tout cas ceux qui existaient en 2001, j'ai pas re-vérifié depuis) pour Haiku c'est compliqué. Pour un build de Haiku il y a 3 compilateurs qui entrent en jeu: un pour compiler des trucs sur le système hôte, et un gcc2 et un gcc11 pour compiler sur la cible. Et au début il nous fallait un outil qui fonctionnait sous BeOS. Sans compter les petits morceaux compilés en assembleur, les astuces pour générer un bootloader EFI valide (qui est en gros un .exe pour Windows mais pas tout à fait), des images de DVD contanant plusieurs systèmes de fichiers, …
On a un moment réfléchi à tenter d'utiliser CMake mais il ne semble pas vraiment assez flexible pour ça. Je crois qu'à l'époque on en avait discuté avec ReactOS, ils utilisent CMake, mais en fait ils avaient une version patchée pour pouvoir faire tout ce qu'ils voulaient.
Maintenant, si un développeur de Boost.Jam se mettait en tête d'intégrer tout ce dont on a besoin dans Boost.Jam, on serait très content de leur refiler la maintenance du système de build et de plus avoir besoin de le faire nous-même. Mais jusqu'à maintenant, ce n'est pas arrivé.
La principale limitation pour l'instant est que seuls les exécutables 64bit sont utilisables. Mais il y a d'autres limitations, par exemple il y a des morceaux pas implémentés pour la 3D (j'ai essayé de lancer MAME par exemple et ça ne fonctionne pas à cause de ça). Il semble y avoir un travail en cours pour implémenter l'accélération 3D avec Vulkan et peut-être de l'accélération matérielle (j'ai du mal à suivre le grand nombre de projets en cours de X512 qui travaille sur beaucoup de sujets à la fois!)
Notre version de Jam a beaucoup divergé de l'original avec des fonctionnalités supplémentaires. En particulier les "build profiles" qui permettent de compiler différentes configurations facilement. Dans notre cas: jam @nightly-raw pour compiler une image de type "nightly build", jam @release-raw pour compiler une image de type "release" (qui contient plus de choses), etc. Un profil permet de customiser pas mal de choses au moment de la compilation.
Dans d'autres projets ces profils pourraient être utilisés pour compiler le même exécutable en release ou en debug, par exemple.
Il faudrait donc reporter ces changements dans Boost.Jam, ce qui est compliqué à faire directement parce qu'ils ont énormément retravaillé l'architecture du code (je le sais parce que j'ai porté des patchs dans l'autre sens, par exemple pour pouvoir générer un compile_commands.json).
C'est un exemple d'incompatibilité, mais il y en a plusieurs autres y compris sur la syntaxe du langage Jam. Ham prévoit à terme de savoir lire les Jamfiles des différentes variantes existantes (Haiku, Boost, Perforce original, et peut-être Freetype Jam).
La deuxième raison:
Ham n'est pas seulement un exécutable, il y a une bibliothèque partagée qui pourrait par exemple être utilisée dans un IDE. Ainsi l'IDE n'aurait pas besoin d'un fichier "projet" séparé mais pourrait utiliser (et modifier) directement les Jamfiles et lancer la compilation sans devoir passer par le lancement d'un outil en ligne de commande. Ce qui permettrait par exemple de recompiler directement juste les fichiers concernés quand on enregistre un fichier .cpp ou .h, en tâche de fond. Sans avoir à re-lire et parser tous les Jamfiles à chaque fois comme quand on lance l'outil en ligne de commande. Ou encore d'avoir un outil en tâche de fond qui fait ça même sans IDE.
Troisième raison:
La coordination entre plusieurs projets (Boost et Haiku par exemple) est souvent compliquée. Ils apprécierait pas forcément qu'on ajoute tous nos trucs dans leur version. Et si le résultat c'est remplacer un fork de Jam par un fork de Boost.Jam, on aura pas gagné grand chose.
Dans la GPL v2 il y a 3 façons de faire dans ce cas:
.3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
Donc en effet, on peut donner le lien vers les sources originales, mais seulement dans le cas d'une distribution non-commerciale ET si on a nous-même reçu l'exécutable de cette façon (c'est l'option C). Ce qui n'est pas notre cas puisqu'on l'a compilé nous-même et qu'on collecte des dons pour le projet en échange de nos DVD.
Donc on a pris l'option A.
Dans la GPL3 des nouvelles possibilités ont été ajoutées:
.6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
L'option B a été pas mal modifiée et maintenant elle permet de fournir un lien de téléchargement. Mais toujours à garder en ligne pendant au moins 3 ans.
Les nouvelles options D et E ne nous concernent pas (pour les DVD en tout cas) puisqu'il s'agit de téléchargement depuis un serveur ou de diffusion en P2P.
D'ailleurs ces clauses sont un peu mal fichues, puisque la D parle d'une durée de distribution, mais en fait la durée dont il est question n'a l'air de s'appliquer que dans le cas B?
Et inversement, dans le cas B il n'est pas précisé si on doit héberger nous-même le code source ou s'il suffit de donner un lien pointant chez quelqu'un d'autre. Alors que l'option D dit explicitement que c'est possible. Cela dit, puisqu'il faut garantir que les données seront disponibles pendant 3 ans, on ne peut pas le faire en pointant sur le serveur FTP du projet GNU, qu'ils pourraient très bien décider de fermer / supprimer des vieux fichiers.
Non mais il y a des gens qui ne souhaitent pas redistribuer des versions, même non modifiées.
Par exemple, moi!
Sur les DVDs du système d'exploitation Haiku, on inclut un certain nombre d'outils de développement, dont, par exemple, GNU make. Comme il est sous licence GPL, si j'envoie un tel DVD à quelqu'un (par la poste, sur un stand au FOSDEM, …) je m'engage à rester à sa disposition pendant 3 ou 5 ans (si je dis pas de bêtise) pour lui donner, par le même moyen, les sources correspondantes.
La licence a été un peu améliorée sur ce point dans la version 3 et maintenant, fournir un lien pour télécharger les sources (qui doit rester valable pendant la même durée) est suffisant.
Au final, pour Haiku, on a mis les sources des applications sous licenses GPL fournies, directement sur le DVD. Ce qui nous empêche de pouvoir faire rentrer notre distribution sur un CD au lieu d'un DVD. Ce qui fait que les DVD coûtent un peu plus cher à produire et donc on récolte moins d'argent par ce moyen (on passe de 87c à 1€ pièce sur un lot de 500 disques). Donc la conformité à la GPL nous a coûté environ 65€.
Ça peut marcher aussi. Ça m'arrive souvent de mélanger du code MIT et GPL dans un projet. L'ensemble est alors soumis aux contraintes de redistribution de la GPL (ou alors il faut réécrire et remplacer les morceaux qui sont sous cette license), mais on peut extraire des parties du code qui sont en MIT pour les réutiliser ailleurs.
Le changement climatique accélère la rotation de la Terre ce qui fait qu'il ne devrait plus y avoir de secondes intercalaires de toutes façons.
… mais pourquoi ces gens utilisent la mauvaise base de temps? Si les secondes intercalaires vous pose problème, utilisez le temps TAI et pas le temps UTC, il est prévu pour ça. Et laissez le temps UTC être synchronisé avec la rotation de la Terre, il est prévu pour ça. Si votre système n'est pas lié à la rotation de la Terre vous n'avez pas besoin du temps UTC.
Alors pardon mais Carbon c'est surtout le framework qui a permis de migrer en douceur de Mac OS 8 vers Mac OS X en pouvant cibler ces 2 systèmes (complètement différents malgré les apparences) avec le même code source.
Sur mon projet actuel, les spécifications ainsi que le code sont en anglais. On utilise des anglicismes pour les mots technique à l'oral, parce qu'on a défini ces mots en anglais et on peut les utiliser avec un sens très précis. C'est parfois même un avantage: pour les mots anglais utilisés ainsi, on peut les détacher assez facilement de leur sens original et les utiliser uniquement dans le sens qu'on leur a donné dans le contexte du projet. Le vocabulaire qu'on peut utiliser s'en trouve ainsi enrichi puisqu'on peut, au besoin, piocher dans le lexique de deux langues différentes.
Par contre sur un projet précédent, les spécifications était en français, mais le code et les commentaires en anglais. Du coup, c'était deux fois plus de travail. Pour chaque concept il fallait trouver deux noms, un en français pour la spec, un en anglais pour le code. En essayant d'éviter les "faux amis", mots qui se ressemblent dans les deux langues mais dont le sens peut en fait être différent (parfois beaucoup, et parfois de façon beaucoup plus subtile).
Bref, le plus simple c'est de travailler dans une seule langue à la fois, et peu importe laquelle.
Pour Telegram, le chiffrement de bout en bout il est surtout dans les arguments marketing. Il n'est pas activé par défaut comme ça pas besoin de s'embêter avec des clés de chiffrement. Mais il existe, donc ils communiquent (beaucoup) dessus.
D'autre part, cette tentative de monétiser Telegram me semble moins nulle que la précédente qui était à base de cryptomonnaies si je me souviens bien?
Alors pour l'occupation mémoire de Python, il existe Micropython, d'après https://lwn.net/Articles/725508/ il peut fonctionner avec 256K de code et 16K de RAM (et c'est en baremetal sans avoir besoin d'un OS en-dessous).
Il ne me semble pas avoir vu Perl faire aussi bien.
D'ailleurs cela laisse entrevoir un autre aspect intéressant de Python: il y a plusieurs implémentations du langage, qui sont adaptées pour différents usages: MicroPython pour l'embarqué avec quelques Ko de RAM, cython quand on a besoin de compiler le code pour qu'il tourne plus vite, etc. On est en fait bien au-delà d'un simple langage de script.
Il va donc peut être remplacer C++ quand il en aura fini avec Perl?
En gros, pour comparer avec des technos modernes, Transpac est similaire à TCP et Cyclades à UDP. C'est aoproximatif comme comparaison, parce que TCP est un protocole très compliqué pour fournir le même service que Transpac: les données envoyées arrivent toutes à destination, et dans le même ordre où elles ont été envoyées.
Ça convient très très bien à un usage de type Minitel et à plein d'autres choses aussi (HTTP, telnet, FTP, SSH, …). Et c'est une façon de penser qui était maîtrisée à l'époque parce que ça se comporte en gros comme un lien série point à point, chose qu'on sait faire au moins depuis l'invention du télétype.
Du coup cela a simplifié probablement l'interfaçage avec des technos existantes, et aussi le développement de nouvelles applications sans avoir à utiliser une façon de réfléchir complètement différente.
Ce n'est que bien plus tard que on a commencé à voir des applications pour des protocoles basés sur UDP et la notion de datagramme.
Je ne sais pas à quel point Transpac a été conservé si longtemps que ça pour le minitel, il me semble que sur la fin, c'était bien de l'internet qui pouvait être utilisé entre le central télétel (qui gérait les numéros 361x) et les services Minitel. Le Minitel lui-même n'est pas vraiment lié à Transpac, c'est juste un terminal avec un modem qui envoie et reçoit ds octets. Peu importe comment c'est encapsulé et routé après.
par défaut le Minitel utilise un mode d'affichage en 40 colonnes et des séquences d'échappement pas du tout standard. Le mode dit "ASCII" passe en 80 colonnes et avec des séquences d'échappement compatibles avec le terminal VT100 (qui est également celui émulé par xterm et plutôt standard un peu partout).
Ça permet donc d'utiliser le Minitel comme un terminal pour tout autre chose que les services Minitel.
Si je passe le Minitel en "mode retourné", est-ce que je peux faire afficher du texte d'un autre Minitel en direct, comme le "Toc toc, Neo" du premier film Matrix ?
Oui, le mode retourné permet de faire communiquer entre eux directement deux Minitel. Ce qui est tapé sur le clavier de l'un s'affiche sur l'écran de l'autre.
Existe-il des reconstitutions des premiers services gratuits, comme l'annuaire ?
http://3611.re dit qu'il le fait mais ça n'a pas l'air de fonctionner chez moi (je pense que le pare-feu de mon entreprise bloque les websockets).
Qu'avaient exactement les gens du ministère en tête au moment de lancer ce réseau au détriment de Cyclades
Je sais pas mais ça a méga bien marché, avec des millions d'utilisateurs pendant une vingtaine d'années. Il y avait un terminal facile à utiliser et pas trop cher à produire, un modèle économique bien fichu (facturation à la minute directement intégrée sur la facture de téléphone, pas besoin de s'inscrire séparément à chaque service).
Je vois pas trop le rapport avec Cyclades qui n'avait rien de tout ça. Au contraire, pour faire marcher du réseau Cyclades sur un Minitel il aurait fallu implémenter des protocoles beaucoup plus compliqués (gestion des pertes de paquets, réordonnancement, etc), ce dont Transpac n'a pas besoin (les paquets arrivent dans l'ordre et il y a plus qu'à afficher les caractères reçus). C'est ça qui a permis de faire un terminal Minitel vraiment pas cher, avec peu de mémoire et un CPU plutôt lent.
(et je ne sais pas trop comment ça fonctionne dans les traitements de texte pour pouvoir comparer et conseiller.)
On peut sélectionner une partie du texte (mot, paragraphe, …) et appuyer sur un bouton "commentaire". Les commentaires s'affichent alors à côté de la page dans des "bulles", associé au texte surligné. On peut ensuite modifier le document et marquer le commentaire comme résolu.
Pour les traitements de texte, on a un outil qui à partir de ça peut nous générer un fichier tableur avec tous les commentaires (indiquant le numéro de page et de paragraphe), et qui peut être utilisé comme fiche de relecture, pour vérifier dans une version suivante du document si les modifications ont bien été faites.
Pour XWiki, on a installé un plugin de commentaires mais on a pas encore mis en place la partie "fiche de relecture" pour l'instant. Ce n'est peut-être pas nécessaire dans le projet sur lequel on utilise XWiki actuellement, ça le sera peut-être pour d'autres clients qui sont beaucoup plus stricts sur le processus de relecture et de validation de documents.
J'utilise Dokuwiki pour des projets personnels et ça me semble quand même assez limité. On peut vraiment générer un export pdf, avec toutes les pages d'une section du wiki, dans le bon ordre?
Pour moi la seule chose qui permet d'organiser les pages dans un dokuwiki, c'est de les présenter dans un certain ordre dans la sidebar, ou éventuellement on peut un peu organiser avec des namespaces.
Je ne sais pas si la gestion des droits est aussi poussée, sur notre wiki il y a certaines pages accessibles par nos clients, certaines par des fournisseurs, et d'autres internes seulement pour nous.
Il y a pas mal d'autres fonctionalités qu'on utilise aussi, par exemple la possibilité de faire des commentaires sur le contenu d'une page (équivalent aux commentaires dans les traitements de texte)
Peut-être que je connaît pas assez bien dokuwiki et tous ses plugins et qu'on pourrait arriver à faire tout ça avec.
Il n'y a qu'à voir ce qu'Apple a pris pour simplement un ralentissement dont le but affiché était de permettre le téléphone de tenir la charge sur une batterie potentiellement usée.
Apple s'est pris une amende parce qu'ils ont fait ça sans prévenir les consommateurs. Il y a donc tromperie: ils ont vendu un smartphone avec un processeur à N GHz et en fait quelques années plus tard il tourne à N/2 GHz.
Donc, il suffit de prévenir les gens: ce smartphone fonctionne pendant 2 ans (ou 3, ou 5), après, il faut le changer. Mais il est moins cher que les concurrents.
Là on arrive sur de l'obsolescence programmée. Qui est peut être aussi interdite dans certains pays, mais certainement pas partout. Donc, ça peut se faire au moins dans les pays ou c'est autorisé.
Je suis pas là pour décider ce qui est Bien ou Mal. J'ai juste oublié l'existence de l'offre data center tout simplement parce que notre wiki a environ 20 utilisateurs. Ce n'était pas volontaire, ça fait 2 ans que le choix d'utiliser xwiki est fait, je me souviens pas de tous les détails, c'est tout.
D'autre part, j'ai dit qu'on utilisait Jira et qu'on est bien embêtés de devoir trouver autre chose, ce qui est plutôt un bon point pour Jira. Ça montre simplement un exemple de comment on peut se retrouver face au mur du jour au lendemain avec un logiciel propriétaire: la license peut changer et la solution utilisée tout simplement plus proposée par le fournisseur. Mais Atlassian fait les choses de façon correcte et nous laisse le temps de préparer notre migration tranquillement si c'est le choix qu'on fait. Et peut-être que finalement on décidera que le coût de mise en place d'un autre outil esttrop important et qu'on préfère payer Atlassian, même si c'est 27K€/an. Ce sera probablement même pas l'abonnement qui nous coûte le plus cher, et comme Jira est utilisé pour plusieurs projets dans l'entreprise, ça se justifie peut-être, en r'partissant les coûts entre les différents clients concernés.
Et il me semble que le contenu de la dépêche n'est pas vide de critiques (constructives, j'espère) sur xwiki.
Enfin je ne pense pas faire du bashing gratuit de logiciel propriétaire ici. Le but est juste de donner un peu de contexte sur comment on a choisi xwiki pour ce projet. D'autres entreprises et projets auront, bien évidemment, d'autres contraintes, d'autres budgets, d'autres possibilités, et je suppose que le combo "petite équipe d'une dizaine de personne + on peut pas stocker les données sur un cloud d'une autre entreprise" n'est pas si courant que ça (sinon Atlassian ferait un effort pour maintenir cette offre)
Oui en effet, ces offres commencent à 27000€/an pour 500 utilisateurs.
À ce prix la, il vaut mieux embaucher quelqu'un pour contribuer à xwiki et développer les plugins nécessaires! C'est donc ce qu'on a fait.
Et il faut aussi qu'on commence à se préoccuper du remplacement de Jira qui a eu à peu près les mêmes changements. On l'utilise encore pour l'instant parce qu'on avait déjà une license, et le support est assuré jusqu'en 2024.
[^] # Re: Pas de fumée sans feu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 8.
Mon ressenti sur l'utilisation des exceptions, après avoir travaillé sur des projets en C et en C++ avec et sans exceptions, c'est plutôt l'inverse.
Sans exceptions, on se retrouve à écrire au moins 3 lignes de code de gestion d'erreur par ligne de code "utile":
Code utile:
Avec gestion d'erreurs:
Si on a une fonction un peu plus longue qui alloue plusieurs resources, ça devient très vite le bazar de s'assurer que on a bien libéré toutes les ressources allouées.
Alors que avec les exceptions et la RAII en C++, ça se fait tout seul: tous les objets alloués sur la pile sont automatiquement libérés lorsqu'on quitte la fonction.
Bien sûr, pour que ça marche bien, il faut que toutes les resources soient liées à l'existence d'un objet sur la pile. Ce qui peut être compliqué si on en a pas l'habitude ou si le projet (ou les bibliothècues utilisées, ou l'OS ciblé) n'a pas été pensé pour.
# monster6502
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le mégaprocesseur : ~2 m³, ~500 kg, ~40 000 transistors. Évalué à 3.
Dans le même genre mais avec des composants un tout petit peu plus miniaturisés:
https://monster6502.com
[^] # Re: Libre ou pas libre, telle n'est pas la question.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien FauxPilot - Clone de GitHub Copilot libre et hors-ligne. Évalué à 2.
Je ne pense pas que la solution ça soit une nouvelle licence ou une nouvelle loi. C'est effectivement une lecture "juridique" du texte de la licence existante.
Le texte de la licence MIT a justement l'avantage d'être extrêmement clair et simple. Il donne le droit de faire tout ce qu'on veut à condition de reproduire le texte de la licence et la notice de copyright.
Alors on peut prendre un.e juriste et lui demander de faire dire à la licence le contraire de ce qui est écrit, mais comme la licence est simple, courte et claire, son travail va être compliqué. Oui, iel pourra tenter des trucs. Mais iel va avoir du mal à trouver quelque chose.
Par exemple, la question "est-ce que github a obtenu une copie du code?" ça va être difficile de dire que non.
À la question "est-ce que Copilot reproduit la licence avec le code quand il le réutilise?" la réponse est clairement non.
Et comme je le disais, la question qui se pose est plutôt "jusqu'où on peut aller si on ne veut pas respecter les termes de la licence?" (dans ce cas, reproduire la licence et la notice de copyright)?
La réponse est là aussi assez simple: c'est le droit d'auteur qui s'applique. Il donne quelques droits "par défaut", j'en ai cité quelques uns. Et c'est plutôt là que le débat va se situer: est-ce que les droits donnés par défaut par le droit d'auteur sont suffisants pour l'utilisation que Github a fait du code? Là, on arrive dans une question plus pointue, et effectivement, comme je ne suis pas juriste de formation, je ne vais pas m'engager dans une réponse à ce niveau là parce que ça dépasse mes compétences. Mais il n'est pas difficile de trouver des informations sur ces droits si on veut se pencher sur la question.
Mais sur la lecture d'une licence et son application dans les cas classiques, je pense que tous les développeurs devraient au moins être sensibilisés au sujet. Ça évite de faire n'importe quoi. Un peu de la même façon qu'on demande aux gens de connaître un minimum le code de la route avant de conduire une voiture, pas tous les articles par cœur, mais de quoi se débrouiller au quotidien dans les situations courantes.
[^] # Re: Libre ou pas libre, telle n'est pas la question.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien FauxPilot - Clone de GitHub Copilot libre et hors-ligne. Évalué à 2.
Voici ce que dit la license:
(avec une clause d'attribution ensuite).
Donc la permission qui est donnée est: "to deal in the Software without restriction", avec quelques exemples non exhaustifs ("including witohut limitation"), dont la redistribution.
Il n'y a pas du tout de limitation à la redistribution ou à la modification du code. Si tu as reçu une copie de ce code (trouvé sur github ou il a été volontairement publié par exemple), tu as le droit de faire ce que tu veux avec sans restriction, tant que tu cites le nom de l'auteur.
Si tu ne cites pas le nom de l'auteur tu as les droits donnés par:
- Les conditions d'utilisations de github (droit pour n'importe qui de forker le dépôt par exemple, ce qui ne fait pas vraiment de copie et donc ne pose pas de problème de droit d'auteur en soi)
- La loi sur le droit d'auteur, qui par défaut interdit tout, sauf accord de l'auteur, et des exceptions pour les courtes citations, parodies, etc (variables selon les pays).
A priori la loi sur le droit d'auteur n'a pas de clause spéciale pour l'analyse automatique. Les conditions d'utilisation de Github, peut-être. Mais si des gens ont déposé sur Github du code dont ils ne sont pas détenteur du copyright, sans l'autorisation dudit détenteur, je vois mal comment les conditions d'utilisations de Github pourraient alors outrepasser la license.
[^] # Re: ♪ A Ham Jam Jam , compile compile compile, A Ham Jam Jam ♪
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a (presque) 21 ans. Évalué à 10.
Dans le pire des cas on va en détruire un (Haiku Jam) pour le remplacer par un autre (Ham). Dans le meilleur des cas, on va en détruire deux (Haiku Jam et Boost Jam) pour les remplacer tous les deux par Ham.
En fait tout cela est assez neutre puisqu'on ne crée pas de nouveaux fichiers de build, on crée un nouvel outil qui utilise les fichiers déjà existants. Qui sont d'ailleurs loin d'être parfaits dans Jam, mais je pense que ça va permettre de travailler sur des aspects intéressants du problème (intégration dans les IDE, meilleur suivi des dépendances, rapidité de parsing des fichiers) en sautant les étapes "réinvention de la roue" de la conception d'un nouveau langage de build.
Peut-être que d'autres outils devraient faire ça? Est-ce qu'on adopterait plus rapidement un outil qui fait "tout comme CMake mais deux fois plus vite" qu'un outil "il faut réécrire tous les scripts de build mais ça va trois fois plus vite"?
Utiliser les outils existants (en tout cas ceux qui existaient en 2001, j'ai pas re-vérifié depuis) pour Haiku c'est compliqué. Pour un build de Haiku il y a 3 compilateurs qui entrent en jeu: un pour compiler des trucs sur le système hôte, et un gcc2 et un gcc11 pour compiler sur la cible. Et au début il nous fallait un outil qui fonctionnait sous BeOS. Sans compter les petits morceaux compilés en assembleur, les astuces pour générer un bootloader EFI valide (qui est en gros un .exe pour Windows mais pas tout à fait), des images de DVD contanant plusieurs systèmes de fichiers, …
On a un moment réfléchi à tenter d'utiliser CMake mais il ne semble pas vraiment assez flexible pour ça. Je crois qu'à l'époque on en avait discuté avec ReactOS, ils utilisent CMake, mais en fait ils avaient une version patchée pour pouvoir faire tout ce qu'ils voulaient.
Maintenant, si un développeur de Boost.Jam se mettait en tête d'intégrer tout ce dont on a besoin dans Boost.Jam, on serait très content de leur refiler la maintenance du système de build et de plus avoir besoin de le faire nous-même. Mais jusqu'à maintenant, ce n'est pas arrivé.
# Typo
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a (presque) 21 ans. Évalué à 3.
On me signale une faute de frappe: il fallait bien sûr lire
mkfset pasmkdspour le nom de l'outil pour formater un disque.[^] # Re: Wine permet de faire quoi pour l'instant ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a (presque) 21 ans. Évalué à 5.
C'est déjà pas mal, non?
La principale limitation pour l'instant est que seuls les exécutables 64bit sont utilisables. Mais il y a d'autres limitations, par exemple il y a des morceaux pas implémentés pour la 3D (j'ai essayé de lancer MAME par exemple et ça ne fonctionne pas à cause de ça). Il semble y avoir un travail en cours pour implémenter l'accélération 3D avec Vulkan et peut-être de l'accélération matérielle (j'ai du mal à suivre le grand nombre de projets en cours de X512 qui travaille sur beaucoup de sujets à la fois!)
Il y a des exemples d'applications avec des captures d'écrans dans ce sujet sur le forum de Haiku: https://discuss.haiku-os.org/t/my-progress-in-porting-wine/11741/169
[^] # Re: ♪ A Ham Jam Jam , compile compile compile, A Ham Jam Jam ♪
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a (presque) 21 ans. Évalué à 10.
Première raison:
Notre version de Jam a beaucoup divergé de l'original avec des fonctionnalités supplémentaires. En particulier les "build profiles" qui permettent de compiler différentes configurations facilement. Dans notre cas:
jam @nightly-rawpour compiler une image de type "nightly build",jam @release-rawpour compiler une image de type "release" (qui contient plus de choses), etc. Un profil permet de customiser pas mal de choses au moment de la compilation.Dans d'autres projets ces profils pourraient être utilisés pour compiler le même exécutable en release ou en debug, par exemple.
Il faudrait donc reporter ces changements dans Boost.Jam, ce qui est compliqué à faire directement parce qu'ils ont énormément retravaillé l'architecture du code (je le sais parce que j'ai porté des patchs dans l'autre sens, par exemple pour pouvoir générer un compile_commands.json).
C'est un exemple d'incompatibilité, mais il y en a plusieurs autres y compris sur la syntaxe du langage Jam. Ham prévoit à terme de savoir lire les Jamfiles des différentes variantes existantes (Haiku, Boost, Perforce original, et peut-être Freetype Jam).
La deuxième raison:
Ham n'est pas seulement un exécutable, il y a une bibliothèque partagée qui pourrait par exemple être utilisée dans un IDE. Ainsi l'IDE n'aurait pas besoin d'un fichier "projet" séparé mais pourrait utiliser (et modifier) directement les Jamfiles et lancer la compilation sans devoir passer par le lancement d'un outil en ligne de commande. Ce qui permettrait par exemple de recompiler directement juste les fichiers concernés quand on enregistre un fichier .cpp ou .h, en tâche de fond. Sans avoir à re-lire et parser tous les Jamfiles à chaque fois comme quand on lance l'outil en ligne de commande. Ou encore d'avoir un outil en tâche de fond qui fait ça même sans IDE.
Troisième raison:
La coordination entre plusieurs projets (Boost et Haiku par exemple) est souvent compliquée. Ils apprécierait pas forcément qu'on ajoute tous nos trucs dans leur version. Et si le résultat c'est remplacer un fork de Jam par un fork de Boost.Jam, on aura pas gagné grand chose.
[^] # Re: Extensions GNU
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Implémentation POSIX de make, dans le domaine public. Évalué à 9.
Dans la GPL v2 il y a 3 façons de faire dans ce cas:
Donc en effet, on peut donner le lien vers les sources originales, mais seulement dans le cas d'une distribution non-commerciale ET si on a nous-même reçu l'exécutable de cette façon (c'est l'option C). Ce qui n'est pas notre cas puisqu'on l'a compilé nous-même et qu'on collecte des dons pour le projet en échange de nos DVD.
Donc on a pris l'option A.
Dans la GPL3 des nouvelles possibilités ont été ajoutées:
L'option B a été pas mal modifiée et maintenant elle permet de fournir un lien de téléchargement. Mais toujours à garder en ligne pendant au moins 3 ans.
Les nouvelles options D et E ne nous concernent pas (pour les DVD en tout cas) puisqu'il s'agit de téléchargement depuis un serveur ou de diffusion en P2P.
D'ailleurs ces clauses sont un peu mal fichues, puisque la D parle d'une durée de distribution, mais en fait la durée dont il est question n'a l'air de s'appliquer que dans le cas B?
Et inversement, dans le cas B il n'est pas précisé si on doit héberger nous-même le code source ou s'il suffit de donner un lien pointant chez quelqu'un d'autre. Alors que l'option D dit explicitement que c'est possible. Cela dit, puisqu'il faut garantir que les données seront disponibles pendant 3 ans, on ne peut pas le faire en pointant sur le serveur FTP du projet GNU, qu'ils pourraient très bien décider de fermer / supprimer des vieux fichiers.
[^] # Re: Extensions GNU
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Implémentation POSIX de make, dans le domaine public. Évalué à 6.
Non mais il y a des gens qui ne souhaitent pas redistribuer des versions, même non modifiées.
Par exemple, moi!
Sur les DVDs du système d'exploitation Haiku, on inclut un certain nombre d'outils de développement, dont, par exemple, GNU make. Comme il est sous licence GPL, si j'envoie un tel DVD à quelqu'un (par la poste, sur un stand au FOSDEM, …) je m'engage à rester à sa disposition pendant 3 ou 5 ans (si je dis pas de bêtise) pour lui donner, par le même moyen, les sources correspondantes.
La licence a été un peu améliorée sur ce point dans la version 3 et maintenant, fournir un lien pour télécharger les sources (qui doit rester valable pendant la même durée) est suffisant.
Au final, pour Haiku, on a mis les sources des applications sous licenses GPL fournies, directement sur le DVD. Ce qui nous empêche de pouvoir faire rentrer notre distribution sur un CD au lieu d'un DVD. Ce qui fait que les DVD coûtent un peu plus cher à produire et donc on récolte moins d'argent par ce moyen (on passe de 87c à 1€ pièce sur un lot de 500 disques). Donc la conformité à la GPL nous a coûté environ 65€.
[^] # Re: L'argent, la solution à tous les problèmes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Why I Use the GPL and Not Cuck Licenses. Évalué à 5.
Ça peut marcher aussi. Ça m'arrive souvent de mélanger du code MIT et GPL dans un projet. L'ensemble est alors soumis aux contraintes de redistribution de la GPL (ou alors il faut réécrire et remplacer les morceaux qui sont sous cette license), mais on peut extraire des parties du code qui sont en MIT pour les réutiliser ailleurs.
# Chagement climatique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les géants de la tech veulent bannir la seconde intercalaire pour éviter les pannes d'Internet. Évalué à 8.
Le changement climatique accélère la rotation de la Terre ce qui fait qu'il ne devrait plus y avoir de secondes intercalaires de toutes façons.
… mais pourquoi ces gens utilisent la mauvaise base de temps? Si les secondes intercalaires vous pose problème, utilisez le temps TAI et pas le temps UTC, il est prévu pour ça. Et laissez le temps UTC être synchronisé avec la rotation de la Terre, il est prévu pour ça. Si votre système n'est pas lié à la rotation de la Terre vous n'avez pas besoin du temps UTC.
[^] # Re: Le nom ne m'arrange pas trop...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Google forke C++. Évalué à 7.
Alors pardon mais Carbon c'est surtout le framework qui a permis de migrer en douceur de Mac OS 8 vers Mac OS X en pouvant cibler ces 2 systèmes (complètement différents malgré les apparences) avec le même code source.
# Le plus fatiguant c'est de mélanger deux langues
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Mon rapport à l'anglais . Évalué à 7.
Sur mon projet actuel, les spécifications ainsi que le code sont en anglais. On utilise des anglicismes pour les mots technique à l'oral, parce qu'on a défini ces mots en anglais et on peut les utiliser avec un sens très précis. C'est parfois même un avantage: pour les mots anglais utilisés ainsi, on peut les détacher assez facilement de leur sens original et les utiliser uniquement dans le sens qu'on leur a donné dans le contexte du projet. Le vocabulaire qu'on peut utiliser s'en trouve ainsi enrichi puisqu'on peut, au besoin, piocher dans le lexique de deux langues différentes.
Par contre sur un projet précédent, les spécifications était en français, mais le code et les commentaires en anglais. Du coup, c'était deux fois plus de travail. Pour chaque concept il fallait trouver deux noms, un en français pour la spec, un en anglais pour le code. En essayant d'éviter les "faux amis", mots qui se ressemblent dans les deux langues mais dont le sens peut en fait être différent (parfois beaucoup, et parfois de façon beaucoup plus subtile).
Bref, le plus simple c'est de travailler dans une seule langue à la fois, et peu importe laquelle.
[^] # Re: Pourquoi pas si ça reste libre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le client Telegram adopte un modèle économique Freemium. Évalué à 2.
Pour Telegram, le chiffrement de bout en bout il est surtout dans les arguments marketing. Il n'est pas activé par défaut comme ça pas besoin de s'embêter avec des clés de chiffrement. Mais il existe, donc ils communiquent (beaucoup) dessus.
D'autre part, cette tentative de monétiser Telegram me semble moins nulle que la précédente qui était à base de cryptomonnaies si je me souviens bien?
# Étiquettes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le client Telegram adopte un modèle économique Freemium. Évalué à 3.
Message à la modération, possibilités de nettoyage dans les étiquettes:
[^] # Re: Vraie question
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien why PERL is still relevant in 2022?. Évalué à 2. Dernière modification le 15 juillet 2022 à 17:06.
Alors pour l'occupation mémoire de Python, il existe Micropython, d'après https://lwn.net/Articles/725508/ il peut fonctionner avec 256K de code et 16K de RAM (et c'est en baremetal sans avoir besoin d'un OS en-dessous).
Il ne me semble pas avoir vu Perl faire aussi bien.
D'ailleurs cela laisse entrevoir un autre aspect intéressant de Python: il y a plusieurs implémentations du langage, qui sont adaptées pour différents usages: MicroPython pour l'embarqué avec quelques Ko de RAM, cython quand on a besoin de compiler le code pour qu'il tourne plus vite, etc. On est en fait bien au-delà d'un simple langage de script.
Il va donc peut être remplacer C++ quand il en aura fini avec Perl?
[^] # Re: En parlant de Minitel
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien OS pour Minitel. Évalué à 8.
En gros, pour comparer avec des technos modernes, Transpac est similaire à TCP et Cyclades à UDP. C'est aoproximatif comme comparaison, parce que TCP est un protocole très compliqué pour fournir le même service que Transpac: les données envoyées arrivent toutes à destination, et dans le même ordre où elles ont été envoyées.
Ça convient très très bien à un usage de type Minitel et à plein d'autres choses aussi (HTTP, telnet, FTP, SSH, …). Et c'est une façon de penser qui était maîtrisée à l'époque parce que ça se comporte en gros comme un lien série point à point, chose qu'on sait faire au moins depuis l'invention du télétype.
Du coup cela a simplifié probablement l'interfaçage avec des technos existantes, et aussi le développement de nouvelles applications sans avoir à utiliser une façon de réfléchir complètement différente.
Ce n'est que bien plus tard que on a commencé à voir des applications pour des protocoles basés sur UDP et la notion de datagramme.
Je ne sais pas à quel point Transpac a été conservé si longtemps que ça pour le minitel, il me semble que sur la fin, c'était bien de l'internet qui pouvait être utilisé entre le central télétel (qui gérait les numéros 361x) et les services Minitel. Le Minitel lui-même n'est pas vraiment lié à Transpac, c'est juste un terminal avec un modem qui envoie et reçoit ds octets. Peu importe comment c'est encapsulé et routé après.
[^] # Re: minitel : terminal pour l'arduino
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien OS pour Minitel. Évalué à 10.
Pour un projet qui tourne vraiment sur le processeur du Minitel (en remplaçant la ROM interne), voir plutôt par ici: http://hxc2001.free.fr/minitel/
[^] # Re: En parlant de Minitel
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien OS pour Minitel. Évalué à 6.
Bien sûr, d'ailleurs plusieurs services sont toujours en ligne et accessibles par ce moyen. Par exemple ceux listés ici (à la fin de l'article après tous les détails techniques): https://cq94.medium.com/dragster-restauration-du-serveur-minitel-pour-macintosh-7ac6b6f3f890
par défaut le Minitel utilise un mode d'affichage en 40 colonnes et des séquences d'échappement pas du tout standard. Le mode dit "ASCII" passe en 80 colonnes et avec des séquences d'échappement compatibles avec le terminal VT100 (qui est également celui émulé par xterm et plutôt standard un peu partout).
Ça permet donc d'utiliser le Minitel comme un terminal pour tout autre chose que les services Minitel.
Oui, le mode retourné permet de faire communiquer entre eux directement deux Minitel. Ce qui est tapé sur le clavier de l'un s'affiche sur l'écran de l'autre.
http://3611.re dit qu'il le fait mais ça n'a pas l'air de fonctionner chez moi (je pense que le pare-feu de mon entreprise bloque les websockets).
Je sais pas mais ça a méga bien marché, avec des millions d'utilisateurs pendant une vingtaine d'années. Il y avait un terminal facile à utiliser et pas trop cher à produire, un modèle économique bien fichu (facturation à la minute directement intégrée sur la facture de téléphone, pas besoin de s'inscrire séparément à chaque service).
Je vois pas trop le rapport avec Cyclades qui n'avait rien de tout ça. Au contraire, pour faire marcher du réseau Cyclades sur un Minitel il aurait fallu implémenter des protocoles beaucoup plus compliqués (gestion des pertes de paquets, réordonnancement, etc), ce dont Transpac n'a pas besoin (les paquets arrivent dans l'ordre et il y a plus qu'à afficher les caractères reçus). C'est ça qui a permis de faire un terminal Minitel vraiment pas cher, avec peu de mémoire et un CPU plutôt lent.
[^] # Re: Dokuwiki ne faisait pas l'affaire ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Utiliser XWiki pour générer une documentation logicielle en PDF. Évalué à 2.
On peut sélectionner une partie du texte (mot, paragraphe, …) et appuyer sur un bouton "commentaire". Les commentaires s'affichent alors à côté de la page dans des "bulles", associé au texte surligné. On peut ensuite modifier le document et marquer le commentaire comme résolu.
Pour les traitements de texte, on a un outil qui à partir de ça peut nous générer un fichier tableur avec tous les commentaires (indiquant le numéro de page et de paragraphe), et qui peut être utilisé comme fiche de relecture, pour vérifier dans une version suivante du document si les modifications ont bien été faites.
Pour XWiki, on a installé un plugin de commentaires mais on a pas encore mis en place la partie "fiche de relecture" pour l'instant. Ce n'est peut-être pas nécessaire dans le projet sur lequel on utilise XWiki actuellement, ça le sera peut-être pour d'autres clients qui sont beaucoup plus stricts sur le processus de relecture et de validation de documents.
[^] # Re: Dokuwiki ne faisait pas l'affaire ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Utiliser XWiki pour générer une documentation logicielle en PDF. Évalué à 2.
J'utilise Dokuwiki pour des projets personnels et ça me semble quand même assez limité. On peut vraiment générer un export pdf, avec toutes les pages d'une section du wiki, dans le bon ordre?
Pour moi la seule chose qui permet d'organiser les pages dans un dokuwiki, c'est de les présenter dans un certain ordre dans la sidebar, ou éventuellement on peut un peu organiser avec des namespaces.
Je ne sais pas si la gestion des droits est aussi poussée, sur notre wiki il y a certaines pages accessibles par nos clients, certaines par des fournisseurs, et d'autres internes seulement pour nous.
Il y a pas mal d'autres fonctionalités qu'on utilise aussi, par exemple la possibilité de faire des commentaires sur le contenu d'une page (équivalent aux commentaires dans les traitements de texte)
Peut-être que je connaît pas assez bien dokuwiki et tous ses plugins et qu'on pourrait arriver à faire tout ça avec.
[^] # Re: Reconditionné
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le marché des smartphones est en chute libre et ce n’est pas près de s’arrêter. Évalué à 3.
Apple s'est pris une amende parce qu'ils ont fait ça sans prévenir les consommateurs. Il y a donc tromperie: ils ont vendu un smartphone avec un processeur à N GHz et en fait quelques années plus tard il tourne à N/2 GHz.
Donc, il suffit de prévenir les gens: ce smartphone fonctionne pendant 2 ans (ou 3, ou 5), après, il faut le changer. Mais il est moins cher que les concurrents.
Là on arrive sur de l'obsolescence programmée. Qui est peut être aussi interdite dans certains pays, mais certainement pas partout. Donc, ça peut se faire au moins dans les pays ou c'est autorisé.
[^] # Re: Petite précision sur l'offre Atlassian
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Utiliser XWiki pour générer une documentation logicielle en PDF. Évalué à 8.
Je suis pas là pour décider ce qui est Bien ou Mal. J'ai juste oublié l'existence de l'offre data center tout simplement parce que notre wiki a environ 20 utilisateurs. Ce n'était pas volontaire, ça fait 2 ans que le choix d'utiliser xwiki est fait, je me souviens pas de tous les détails, c'est tout.
D'autre part, j'ai dit qu'on utilisait Jira et qu'on est bien embêtés de devoir trouver autre chose, ce qui est plutôt un bon point pour Jira. Ça montre simplement un exemple de comment on peut se retrouver face au mur du jour au lendemain avec un logiciel propriétaire: la license peut changer et la solution utilisée tout simplement plus proposée par le fournisseur. Mais Atlassian fait les choses de façon correcte et nous laisse le temps de préparer notre migration tranquillement si c'est le choix qu'on fait. Et peut-être que finalement on décidera que le coût de mise en place d'un autre outil esttrop important et qu'on préfère payer Atlassian, même si c'est 27K€/an. Ce sera probablement même pas l'abonnement qui nous coûte le plus cher, et comme Jira est utilisé pour plusieurs projets dans l'entreprise, ça se justifie peut-être, en r'partissant les coûts entre les différents clients concernés.
Et il me semble que le contenu de la dépêche n'est pas vide de critiques (constructives, j'espère) sur xwiki.
Enfin je ne pense pas faire du bashing gratuit de logiciel propriétaire ici. Le but est juste de donner un peu de contexte sur comment on a choisi xwiki pour ce projet. D'autres entreprises et projets auront, bien évidemment, d'autres contraintes, d'autres budgets, d'autres possibilités, et je suppose que le combo "petite équipe d'une dizaine de personne + on peut pas stocker les données sur un cloud d'une autre entreprise" n'est pas si courant que ça (sinon Atlassian ferait un effort pour maintenir cette offre)
[^] # Re: Petite précision sur l'offre Atlassian
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Utiliser XWiki pour générer une documentation logicielle en PDF. Évalué à 5. Dernière modification le 02 juillet 2022 à 16:05.
Oui en effet, ces offres commencent à 27000€/an pour 500 utilisateurs.
À ce prix la, il vaut mieux embaucher quelqu'un pour contribuer à xwiki et développer les plugins nécessaires! C'est donc ce qu'on a fait.
Et il faut aussi qu'on commence à se préoccuper du remplacement de Jira qui a eu à peu près les mêmes changements. On l'utilise encore pour l'instant parce qu'on avait déjà une license, et le support est assuré jusqu'en 2024.