Une nouvelle compilation de logiciels libres pour Windows est disponible. Plus de 60 logiciels libres ont été sélectionnés en suivant autant que possible ces critères :
- richesse fonctionnelle ;
- licence(s) libre(s), de préférences copyleftées et compatibles avec les licences GNU ;
- logiciels existants sous Windows, GNU/Linux, Mac OS X ;
- pérennité du logiciel : développement actif, communauté importante ;
- utilisation de langages et de bibliothèques indépendantes de Windows ;
- version française.
NdM : il faut l'acheter pour connaître la liste des logiciels libres concernés et les versions présentes ; cette liste est prévue pour évoluer.
Les logiciels sont distribués avec l’installeur COMPILIBRE qui :
- affiche la liste des logiciels, triés par catégories ou par ordre alphabétique ;
- affiche la description de chaque logiciel ;
- permet de copier ou d’installer chaque logiciel sur son ordinateur, en suivant les instructions d’installation ;
- permet de consulter le site web de chaque logiciel ;
- affiche des documentations ou permet de les copier sur son ordinateur.
Avant d’être ajouté dans la compilation, chaque logiciel a été installé sur une version originale et à jour de Windows XP Pro et de Windows 7, dans VirtualBox. Cela a permis de vérifier les dépendances (Ghostscript, Visual C++ 2008, 2010, 2012, 2013, Java, .NET…) en 32 ou en 64 bits, de choisir les paramètres d’installation, de vérifier le bon fonctionnement du logiciel et de connaître les paramétrages indispensables avant de l’utiliser (choix de la langue par exemple). Toutes ces informations sont ajoutées dans la compilation, ce qui garantit une installation réussie des logiciels et fait gagner beaucoup de temps.
Si vous cherchez un prestataire pour une formation ou du développement de logiciel libre, la compilation inclut des annuaires des Entreprises du Numérique Libre (uniquement en Lorraine pour l’instant).
Vous pouvez acheter la compilation sur Prof Tux ou sur Libre-Shop, en téléchargement ou sur une clé USB. Cette version sera mise à jour en permanence. Il est notamment prévu de remplacer Java par OpenJDK dans les logiciels distribués.
Vous pouvez aussi proposer d’autres logiciels et aider à améliorer l’installeur COMPILIBRE (programmation, graphisme, traductions…). Vous pouvez aussi faire un don, ce qui permettra de rémunérer un stagiaire en développement informatique lorsqu’il y aura assez de dons. Lors du stage, il sera notamment prévu de remplacer MySQL par SQLite ou par un autre système de stockage de données plus portable, de faciliter l’internationalisation et d’intégrer Raptor Editor.
Si vous souhaitez avoir une compilation de logiciels libres personnalisée, écrivez à david.vantyghem@free.fr. Dans l’avenir, le système ReactOS sera aussi pris en compte.
Aller plus loin
- Acheter la compilation sur Prof Tux (682 clics)
- Acheter la compilation sur Libre-Shop (271 clics)
- COMPILIBRE (990 clics)
- Raptor Editor (301 clics)
- ReactOS (497 clics)
# ReactOS, vraiment?
Posté par freem . Évalué à 6.
Je suis intrigué, vraiment.
J'aime bien l'idée, tant de distribuer des outils qui marchent sous ReactOS que l'idée même de ReactOS, mais la dernière fois que je l'ai testé, il était d'une simplicité enfantine de générer un BSOD, juste en changeant les locales et en allant jouer avec les menus.
Ne serait-il pas plus pertinent, et plus économe en terme de temps pour ceux qui feront le travail, de se concentrer sur wine, qui au moins ne fait pas segfault le kernel, et ça permettrait de faciliter les transitions de windows vers linux (avoir des outils dont il est «garantit» qu'ils marchent aussi bien sous win que sous wine aide. Je dirais même que je doute qu'il soit possible de faire autrement sans une sacrée dose de volonté).
PS: je pense que si j'avais voulu faire de la pub autour d'un tel projet, j'aurai au moins cité certains logiciels phares. Le secret du contenu ne fera pas grand chose: il suffit probablement d'aller sur framasoft pour deviner les noms.
[^] # Re: ReactOS, vraiment?
Posté par NumOpen . Évalué à 2.
"Ne serait-il pas plus pertinent, et plus économe en terme de temps pour ceux qui feront le travail, de se concentrer sur wine" : toute contribution au projet est la bienvenue et tout le monde peut télécharger COMPILIBRE et créer sa propre compilation, y compris pour Wine.
[^] # Re: ReactOS, vraiment?
Posté par freem . Évalué à 2.
J'ai dû mal comprendre. COMPILIBRE, ce n'est pas le logiciel qui sert de gestionnaire de paquets? Je pensais que c'était les logiciels proposés qui allaient être testés sous ReactOS.
[^] # Re: ReactOS, vraiment?
Posté par NumOpen . Évalué à 2.
Oui, c'est ça. Mais les utilisateurs d'une compilation peuvent aussi contribuer au choix des logiciels, remonter des avis etc. s'ils le souhaitent.
[^] # Re: ReactOS, vraiment?
Posté par Renault (site web personnel) . Évalué à 8.
ReactOS et WINE partagent beaucoup d'informations entre eux et des patchs, améliorer directement ou indirectement ReactOS peut faire progresser WINE et vice-versa.
[^] # Re: ReactOS, vraiment?
Posté par freem . Évalué à 2.
C'est vrai, mais la tâche de ReactOS est d'un tout autre niveau que celle de wine: la ou wine implémente de "simples" APIs, ReactOS c'est une distribution complète, kernel, pilotes, environnement graphique…. et APIs, bien sûr.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ReactOS, vraiment?
Posté par freem . Évalué à 2.
Je ne pense pas. Notes: je ne pense pas ;)
Et ce, parce que même si je suis sûr qu'une bonne partie de l'implémentation de wine est en commun, il y à un moment où il faut cogner dans le kernel: lister les processus, ouvrir un lire un fichier de façon non-bloquante, ce genre de choses. Et là, je ne vois que 2 solutions:
1) ReactOS est POSIX (ou essaie de l'être sans en être sûr, comme Linux donc). Dans ce cas, on passe du kernel vers une DLL vers le kernel à nouveau… niveau perf, ça me semble mauvais, et dans ce cas autant utiliser directement un kernel plus classique.
2) Reactos n'est pas POSIX, et dans ce cas, il faut implémenter les APIs les plus basses soi-même, ok, tout en pouvant profiter d'une partie de wine.
À mon avis, l'option qu'ils ont prise est la 2nde.
Dans les 2 cas, il y à un travail énorme de reverse engineering, mais dans le cas de ReactOS tu as, en plus, besoin d'être assez pointu pour être capable d'écrire les outils de gestion de la RAM, et de mémoire, ce n'est pas trivial du tout. Je ne parlerais pas des techniques d'adressage "sécurisées" parce que je ne pense pas qu'ils s'embêtent avec ça au stade alpha…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 12 janvier 2015 à 17:33.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ReactOS, vraiment?
Posté par freem . Évalué à 3.
Je vois ça.
Oui, je connais cygwin.
Par contre, tu te trompes, ça n'à rien à voir avec un «wine inversé». Je cite:
Et personnellement, la fois ou j'ai essayé de l'installer, je l'ai trouvé trop pénible. Ça remonte, mais, de mémoire, le "gestionnaire de paquet" (enfin, l'outil qui indique ce qu'on essaie d'installer) n'était pas spécialement agréable à utiliser et pullait beaucoup de chose, histoire de bien pourrir la bande passante.
Là, quelqu'un l'a installé sur une VM au boulot, et ça fait plus comme si on faisait tourner "linux" sur windows, que comme si on avait accès aux outils "linux" sous windows (ok, pas linux, les coreutils en fait).
Perso mon kit de survie sous Windows ne l'inclue pas, j'avais trouvé les coreutils portés sous windows, et maintenant il suffit d'installer git pour se retrouver avec bash, ssh, grep, find & co. Pour l'émulateur de terminal j'ai trouvé il y à quelques temps conemu, et pour la compilation mingw fonctionne très bien.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ReactOS, vraiment?
Posté par freem . Évalué à 3.
Moi non plus.
Porter des softs à toujours représenté un gros boulot quand les softs en question ne sont pas prévus pour être simples à porter. Et vue la mentalité de GNU, je doute fortement qu'ils aient fait le moindre effort pour une potentielle compat windows (bien que cygwin comme mingw aient réussi).
Porter bash n'a vraiment pas dû être simple, et la glibc à du être une horreur (modifier tous les appels au kernel doit être plutôt fastidieux, avec le risque d'erreur que ça implique, sans compter le fait que si j'en crois le peu que j'ai lu de l'implem GNU de la STL, je doute que le code soit super lisible, même avec tabwidth=6 pour contrer les effets des espaces + tabs mélangés).
Pour le coup, je pense que l'arrivée de clang et de projets du genre compiler tout Debian avec clang doit pas mal aider, et perso j'ai nettement plus confiance dans les dev de clang pour faire un truc plus simple à porter (J'allais dire qu'il faudrait encore que clang tourne sous windows, mais en fait ça à l'air d'être le cas.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ReactOS, vraiment?
Posté par freem . Évalué à 2.
Je n'ai jamais osé, perso.
Il me suffit de constater le simple fait que le code de la STL est plutôt difficile à lire (bon, ça, à la rigueur… c'est du template après tout, mais malgré tout je pense que ça pourrait être mieux écrit/documenté. Enfin, avec l'habitude j'arrive à en extraire quelques infos…) et mélange des espaces et des tabulations (d'ailleurs, pour ceux que ça intéresse, je pense que les dev de ce truc utilisent un tabwidth de 6… pas commun comme nombre. 8, 4, 2, ok, mais 6 je vois que chez eux).
Ah, il y à aussi le fait que j'aie lu leurs coding guidelines, il y à quelques années (ça fait mal de parler d'années en fait… progboards me semble encore avant-hier). Il y avait pas mal de choses qui m'étaient rédhibitoire dedans (déjà, seule l'utilisation du langage C était acceptée quand le but n'est pas de faire un logiciel dédié à un langage particulier…).
D'ailleurs, c'est un autre argument qui me donne envie de passer à BSD: me semble qu'il y à peu l'un des BSD à switché sur clang par défaut.
Yep. Mais c'est trop tard, en ce qui me concerne, dès que j'aurai l'occasion de me passer complètement de GCC, ce sera avec bonheur. De manière générale, j'ai du mal avec GNU, je les trouve trop extrêmes dans pas mal de choix. Mais bon, utiliser GNU sous linux, c'est la voie de la facilité aussi ;)
D'ailleurs suis content, j'ai découvert il y à peu un repo clang basé sur libstdc++4.7 pour debian stable, je peux enfin utiliser clang et le C++11 sans utiliser Jessie (bon, j'avais surtout pas cherché avant, parce qu'avant je ne voyais pas de problème à utiliser des paquets testing sur une debian stable)!
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ReactOS, vraiment?
Posté par Pierre Schweitzer (site web personnel) . Évalué à 8.
Bonjour freem et les autres,
ReactOS et Wine sont deux choses différentes MAIS complémentaires. L'effort fournit à l'un contribue à l'autre. Il est donc peu enviable que les développeurs de l'un se concentrent sur l'autre projet. Chaque projet a sa masse de développeurs qui y contribuent et tant mieux !
Pourquoi ?
ReactOS a pour objectif de fournir une compatibilité à tous niveaux pour les binaires qui tournent sous Windows, qu'ils soient de simples exécutables ou des pilotes systèmes plus complexes. Dernier exemple en date : le pilote de RamDisk de Windows 2003 tourne sous ReactOS. Je doute qu'il tourne sous Wine ;-).
Wine se concentre en revanche sur une compatibilité maximale et multiversion de Windows sur Linux en mode utilisateur. Si ça restreint ce qu'on peut faire tourner, le spectre des versions couvertes de Windows peut être un gros atout.
Et finalement, ReactOS a besoin de Wine pour aller plus vite dans son implémentation des bibliothèques utilisateurs et Wine a besoin de ReactOS pour le debug, l'utilisation en condition "proche" de Windows, pour les features qui manquent, etc.
Les contributeurs Wine contribuent malgré eux (ou volontairement ;-)) à Wine, et beaucoup de développeurs ReactOS contribuent à Wine (cf : la liste des contributeurs Wine).
Bref, ce sont deux projets complémentaires (et à mon sens nécessaires).
Au passage, vis-à-vis de l'instabilité de ReactOS, il ne faut pas oublier que le développement d'un système d'exploitation from scratch est une chose compliquée. ReactOS fait déjà 10M de ligne de code. C'est un gros projet. Et il se stabilise de plus en plus, mais Rome ne s'est pas faite en un jour.
Tous les volontaires (que ce soit pour développer, tester, traduire, supporter, etc) sont les bienvenus.
Enfin, ReactOS aura un stand aux FOSDEM, si des personnes sont intéressées ;-).
Cordialement,
P. Schweitzer
[^] # Re: ReactOS, vraiment?
Posté par freem . Évalué à 5.
Loin de moi, très très loin de moi même, de considérer que l'écriture d'un kernel est facile.
J'ai beaucoup d'admiration pour le projet, mais ça ne m'empêche pas d'être réaliste, et en tant que développeur, même si j'en reconnais l'intérêt pédagogique ou pour debug une appli windows sans avoir à payer une licence (je prie pour que le jour ou je referais du dev spécifique windows soit le plus loin possible, ceci dit), voire pour permettre de détecter les bugs et comportements indéfinis plus facilement (plus on peut tester sur de nombreux environnements, plus on à de chances de trouver, et corriger les UB avant que ça n'explose), il n'empêche qu'il ne me viendrait pas, en l'état, l'idée de baser du travail sur ReactOS. Sauf si j'en venais à avoir le niveau + la motivation + le temps de travailler sur ReactOS lui-même, bien sûr.
Quant au fait que wine et ReactOS soient complémentaires, ça me semble évident. On discutait juste du niveau de profondeur de la complémentarité (en tout cas, en ce qui me concerne).
# Compilation et visibilité
Posté par cosmocat . Évalué à 4.
Je me pose la question : Qui utilise encore des système de compilation? Est-ce que ça apporte de la visibilité pour les logiciels libres?
Car personnellement, je pense qu'un gestionnaire de "paquets" comme https://chocolatey.org/ apporte plus d'avantages et qu'il aurait mieux valut ajouter tous les logiciels manquant à ce gestionnaire de paquets… quitte à faire pourquoi pas un site pour la compilation présentant les logiciels!
# Désolé mais...
Posté par Xavier Verne (site web personnel) . Évalué à 6.
J'ai parcouru les liens et NE pas savoir la liste des logiciels que l'on "achète" pour avoir un truc clé en main, c'est juste… rédhibitoire, non ?
Au départ j'ai cru que je regardais mal, mais il semblerait que non si je vois la note des modéros. Messieurs Prof Tux et LibreShop, une suggestion, trouvez un moyen de lister au moins quelques logiciels phares - si vous ne voulez pas tenir les mises à jour - pour qu'on ait envie d'en faire la pub et de la recommander ou d'acheter la clé USB.
[^] # Re: Désolé mais...
Posté par NumOpen . Évalué à 0.
Il y a un logiciel pour ajouter et modifier des sous-titres dans une vidéo, pour chiffrer ses fichiers, un éditeur de textes, un logiciel de sauvegarde, un logiciel de traitement du son, un logiciel de dessin 3D, un éditeur HTML5, un enregistreur vidéo de son écran, une imprimante PDF, un graveur de CD/DVD/BD, un antivirus résident, un gestionnaire/lecteur de musiques, un convertisseur d'unités, un éditeur de bases de données, un logiciel de dessin de diagrammes, un logiciel de gestion de la relation client/facturation/gestion commerciale, un dédoubleur de fichiers, un pack Apache/PHP/MySQL, un outil de recherche de caractères dans les fichiers, un logiciel de transfert par FTP, un aspirateur de sites Web, des logiciels de CAO 2D et 3D, un éditeur de cartes heuristiques, un outil de synchronisation de dossiers, un logiciel de retouche d'images, des pense-bêtes, du chiffrement de courriels, un éditeur de fichiers GPS, un logiciel de copie d'écran, un serveur de messagerie, un logiciel de dessin vectoriel, un logiciel de tchat/téléphonie SIP/visioconférence/partage de bureau, une suite EDA, une suite bureautique, un logiciel de composition musicale, un comparateur de fichiers, un testeur de RAM, un renommeur de fichiers en masse, un gestionnaire/lecteur multimédia, un navigateur Web, une messagerie, un éditeur de partitions musicales, un logiciel de dessin avec tablette graphique, une protection des clés USB, une synthèse vocale, un logiciel de gestion commerciale/comptabilité analytique/paye/point de vente, un manipulateur de fichiers PDF, un gestionnaire de fichiers compressés, un planificateur de tâches, un logiciel de schémas électriques, un réseau logiciel d'échanges chiffrés en F2F, une transmission RS232 pour les MOCN, un logiciel de PAO, du montage vidéo, un visualiseur PDF, un logiciel de dessin d'aménagement de pièces, un récupérateur de données effacées, un moteur de rendu 3D pour créer des jeux, un comparateur de fontes, un lecteur multimédia, un gestionnaire de fichiers ISO, un générateur de codes barres…
:o)
[^] # Re: Désolé mais...
Posté par freem . Évalué à 3.
Ce n'est pas la question de savoir quels types d'outils il y à.
La question, c'est de connaître au moins le nom de quelques logiciels phare, parce que je doute que, sur linuxfr, des gens vont recommander à leurs proches éloignés de l'informatique une collection de soft dont on ne sait même pas si on saurait dépanner les logiciels les plus en vue, faute de nom.
Franchement, je pense que ça ne serait pas un problème de citer sumatra, firefox, thunderbird, gimp, etc (je suppose pour les soft hein, je pourrais me tromper).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.