Près de dix ans après la version 0.3.0, le projet ReactOS a annoncé sa version 0.4.0 le 16 février 2016. ReactOS est une distribution logicielle libre un peu spéciale : elle propose un noyau NT et un environnement visant à reproduire les fonctionnalités de base d’un système d’exploitation Windows.
ReactOS n'est pas un clone libre de Windows mais un système d'exploitation libre compatible avec Windows. La précédente dépêche nous a tracé, il y a presque deux ans, un état des lieux à l'orée d'une campagne de financement participatif.
Le projet est également réputé pour sa capacité à documenter les fonctionnalités non-documentées de Windows, ce qui peut intéresser du monde qui ne serait pas directement intéressé par le système lui-même, et pour sa collaboration avec le projet WINE. En effet une grande part des bibliothèques en espace utilisateur proviennent directement de WINE et ReactOS travaille à remonter autant que possible les modifications.
C’est un projet très ambitieux : il ne s’agit pas seulement de développer un noyau, mais aussi de développer l’environnement utilisateur (comme le shell explorer.exe) et d’assurer la compatibilité avec la très vaste logithèque Windows, ce qui ajoute à la difficulté de l’exercice des contraintes très fortes. On peut le voir à la longueur du ChangeLog qui liste un très grand nombre de corrections visant à faire fonctionner des logiciels tiers.
Sommaire
- In memoriam
- Fonctions
- Modernisation de la compilation
- Systèmes de fichiers
- Affichage
- Gestion de la mémoire
- Réseaux
- NT Virtual Dos Machine
- Base de registre
- Le shell
- Stockage
- Son
- USB
- Aspect visuel
- En route vers la Beta
Bien qu’étant une étape majeure pour le projet, cette version 0.4.0 est toujours étiquetée Alpha, mais la série 0.4.x sera la dernière à l’être, la prochaine série 0.5.0 sera une version Beta (voir la nomenclature officielle des versions de ReactOS).
Cette dépêche reprend assez librement la note de sortie officielle.
In memoriam
Dans la note de sortie, l’équipe tient à remercier et honorer particulièrement la mémoire de contributeurs qui ont permis que ReactOS devienne ce qu’il est devenu aujourd’hui :
« On ne peut pas insister suffisamment sur le fait que le projet ReactOS est là où il est aujourd’hui grâce aux efforts sans relâche d’individus qui le portent. Au cours de son évolution, certains sont arrivés et d’autres sont partis, mais tous ont laissé une marque, qu’elle soit dans le code source ou dans la mémoire des échanges avec ceux encore actifs dans le projet. Malheureusement, dans deux cas, ces souvenirs sont tout ce qui nous restera. Gé van Geldorp fut un des premiers développeurs et fut fort impliqué dans la mise au point du sous-système win32. Il a aussi pris sous son aile de nombreux autres développeurs qui ont rejoint le projet par la suite et qui se souviennent de son avidité à aider ceux qui débutaient. Brandon Mark Turner fut un autre des premières heures du projet. Il a travaillé sur une variété de composants et fut responsable du travail initial qui a permis de compiler ReactOS avec les outils de Microsoft. La version 0.4.0 leur est dédiée et nous espérons que son aboutissement puisse montrer à quel point nous leur en sommes immensément reconnaissants. »
Fonctions
Ici sont documentées non seulement les nouveautés depuis la version 0.3.17, mais aussi toutes les avancées reposant sur l’effort cumulatif de toute la série des versions 0.3.x. En résumé, les nouvelles fonctionnalités sont :
Pour l’utilisateur
- Prise en charge d’ext2 en lecture et écriture (système de fichiers historique du noyau Linux), et de NTFS en lecture seule ;
- Nouvel explorateur (explorer_new) avec prise en charge de thèmes ;
- Prise en charge des périphériques SerialATA (UniATA) ;
- Prise en charge du son ;
- Prise en charge des périphériques USB ;
- Prise en charge de VirtualBox et de VirtualPC ;
- Réseau sans fil.
Pour le développeur
- Utilisation de CMake pour compiler avec GCC ou MSVC ;
- Temps de compilation réduit de manière significative ;
- Débogage à distance du noyau via GDB ;
- Prise en charge de WinDBG.
ReactOS n’est pas encore très stable pour une utilisation quotidienne, mais il fait déjà tourner nombre d’applications populaires, qu’elles soient libres ou propriétaires.
Modernisation de la compilation
Alors que les versions précédentes utilisaient un système fait maison — RBuild, basé sur des fichiers XML — qui bien qu’ayant des fonctionnalités très impressionnantes pour son époque, souffre de certains défauts subtils et empêche l’utilisation d’un autre compilateur que GCC, cette nouvelle version utilise désormais CMake.
Systèmes de fichiers
Historiquement, ReactOS dépendait des systèmes de fichiers de type FAT. Alors que la communauté attendait quelque chose de plus évolué, ce but restait difficile à atteindre pour des raisons de complexité technique. La prise en charge d’ext2 est complète, cette version est la première à permettre la lecture de NTFS (et btrfs pourrait venir dans une prochaine version !).
Affichage
Il y a eu de nombreuses améliorations de la prise en charge de la 2D et de la 3D. Des optimisations concernant l’accélération 2D ont eu lieu, celle-ci étant même dans certains cas plus rapide que Windows. La gestion de la 3D, initiée dans la version 0.3.7, a progressé. De plus, certains correctifs issus de la version 0.3.8 ont permis de charger correctement les pilotes graphiques. Voilà un grand pas de plus vers l’objectif de compatibilité !
Gestion de la mémoire
La gestion de la mémoire, composant central à tout système d’exploitation, a été fortement travaillée pour la version 0.3.15. Bien qu’il reste encore du travail, ceci constitue néanmoins une avancée significative sur le plan de la stabilité.
Réseaux
Depuis la prise en charge initiale des réseaux par la version 0.3.0, celle-ci n’a cessé d’être améliorée. Cette version inclut notamment des corrections de la gestion du Wi-Fi (introduit dans la version 0.3.14) et, depuis la version 0.3.17, la prise en charge de SSL par l’intermédiaire de la bibliothèque mbed TLS.
NT Virtual Dos Machine
Une demande récurrente de la communauté était la prise en charge des applications DOS 16 bits. Sous Windows, c’est le boulot de la NT Virtual DOS Machine (NTVDM). Son implémentation par ReactOS a vu le jour avec la version 0.3.17. Depuis, ses considérables améliorations permettent aux testeurs de ressusciter d’anciens jeux. Un avantage remarquable de cette implémentation est qu’elle continuera de fonctionner sur processeurs non IA32 (Intel x86) tels que AMD64 et même ARM, lorsque ces ports seront aboutis.
Base de registre
Qu’on l’aime ou pas, la base de registre est un composant essentiel de la famille Windows. En tant qu’implémentation de NT, ReactOS en possède aussi une. Non seulement celle-ci fonctionne de manière fiable, mais ReactOS peut aussi lire et modifier celles en provenance de Windows, permettant notamment au bootloader de ReactOS de démarrer Windows 2003.
Originalité de ReactOS, la base de registre peut également être parcourue depuis l’explorateur de fichier !
Le shell
L’explorateur utilisé par la version 0.3.0 est issu de la version 0.2.0. À cette époque, ReactOS n’offrait pas l’infrastructure nécessaire à son implémentation rigoureuse, forçant celui-ci à dupliquer l’essentiel des fonctionnalités qui auraient dû être rendues disponibles par le système d’exploitation. De plus, lorsque celles-ci furent disponibles via ce qu’on appelle le shell, il n’en profita pas. Cette version synthétise donc un travail important sur le shell ainsi qu’une toute nouvelle implémentation de l’explorateur, une des vraies nouveautés de cette version 0.4.0.
Pour l’anecdote, ce nouvel explorateur a été d’abord développé comme un explorateur de remplacement pour Windows en attendant que ReactOS implémente les fonctionnalités nécessaires et devienne capable de le faire tourner. L’intégration de cet explorateur témoigne donc significativement de la compatibilité de ReactOS avec Windows, et comment certains composants critiques peuvent être interchangés.
Stockage
Tout comme les connecteurs PS/2 tombés en désuétude, l’interface IDE est remplacée dans les ordinateurs actuels par l’interface SATA. ReactOS a introduit sa prise en charge dans la version 0.3.10 par l’incorporation du pilote UniATA et en a depuis amélioré le fonctionnement.
Son
La prise en charge du son, qui pourrait être vue comme une fonctionnalité de base, s’est avérée une tâche complexe. Depuis son introduction dans la version 0.3.9, elle a été améliorée pour passer d’une situation où l’on s’étonne que cela marche, à celle où il est normal que cela fonctionne.
USB
Le support préliminaire des claviers et souris, introduit dans la version 0.3.10, a été supplanté par une pile USB complète. Celle-ci a été introduite initialement dans la version 0.3.15 et a été continuellement améliorée depuis.
Aspect visuel
Une demande récurrente était d’avoir un shell à l’aspect plus agréable. Le chemin a été semé d’embûches, néanmoins la version 0.3.16 a été publiée avec un nouveau thème — Lautus — à destination des curieux.
À gauche, le thème classique, à droite, le thème Lautus :
En route vers la Beta
Il reste fortement déconseillé d’utiliser ReactOS en production. Si la stabilité n’est pas encore au rendez-vous, son niveau de fonctionnalités commence cependant à devenir satisfaisant. Espérons que tout cela soit stabilisé rapidement !
ReactOS peut être téléchargé ici (images CD d’installation, images de disque prêtes à virtualiser…). Les plus intrépides qui souhaiteraient l’installer sur du vrai matériel peuvent se référer à cette liste (non exhaustive) de matériel supporté avant de sauter le pas. Et en route pour la 0.5.0 qui devrait apporter entre autres la prise en charge de l’impression, et l’écriture dans les systèmes de fichier NTFS !
Si vous êtes un développeur d’application Windows, n’hésitez pas à tester votre production avec ReactOS et remonter le problème s’il vient clairement d’un manque ou d’une erreur de ReactOS. Si vous êtes un développeur de pilote pour Windows (système de fichier, prise en charge de matériel, etc.), sachez que si votre pilote est libre, votre travail pourrait contribuer directement au projet ReactOS.
Aller plus loin
- [ReactOS.org] ReactOS 0.4.0 Released (1632 clics)
- [ReactOS.org] ChangeLog-0.4.0 (232 clics)
- [LinuxFr.org] ReactOS : officialisation et financement (1767 clics)
# Noyau NT
Posté par Eiffel . Évalué à 9.
Si je comprend bien ReactOS est un noyau NT libre.
Mais comment ont-ils fait pour écrire un tel noyau ? Car six jeunes m'abusent ce noyau n'est pas très documenté.
En tout cas les développeurs doivent être balaises en rétro-ingénierie, bravo à eux !
[^] # Re: Noyau NT
Posté par Shunesburg69 . Évalué à -3.
D'ailleurs, il devrait lui trouver un autre nom, c'est comme si on appelait Linux Unix.
[^] # Re: Noyau NT
Posté par El Titi . Évalué à 2.
Au hasard:
WindwOS
[^] # Re: Noyau NT
Posté par Shunesburg69 . Évalué à 0.
Ou WineDose
[^] # Re: Noyau NT
Posté par rogo . Évalué à 6.
ReactOS n'est pas qu'un noyau NT libre. À moins que j'ai compris de travers la dépêche, ReactOS contient un noyau compatible avec NT, mais implémente aussi des surcouches applicatives.
Une bonne part de ce que veut ré-implémenter ReactOS est très bien documentée, même si cette documentation est destinée à des développeurs qui souhaitent utiliser les API de Windows dans leur programme, et non construire une implémentation alternative.
Certes, le noyau n'est pas officiellement documenté, puisqu'il n'est pas publié. Par contre, le code source des noyaux de Win200 et NT4 avait fuité en 2004. On peut supposer que cela a beaucoup allégé la charge de rétro-ingénierie sur cette partie.
[^] # Re: Noyau NT
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Pas sûr, perso dans ce genre de situation je préfère ne pas regarder. En fait je vois toujours d’un mauvais œil ce genre de fuite parce que ça ouvre à des suspicions. Il est plus facile de se prévaloir de ne pas avoir copié collé sauvagement du code quand il est de notoriété publique que tu n’as pas pu accéder au code. Je ne suis pas certain que ce genre de « fuite » profite réellement au logiciel libre, bien au contraire.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Noyau NT
Posté par pasBill pasGates . Évalué à 10.
Il y a en fait pas mal de doc sur le design du noyau qui décrivent comment le memory manager, object manager, scheduler, … se comportent.
Windows Internals, Windows NT Device Driver Development, … décrivent de larges parties du kernel en long et en large.
[^] # Re: Noyau NT
Posté par Shunesburg69 . Évalué à 2.
C'est justement pour ça que plus haut je disais qu'il faudrait qu'il le nomme car ce n'est pas un noyau NT mais un noyau compatible NT, tout comme Linux n'est pas un noyau UNIX mais un noyau compatible UNIX. Bizarrement les gens ont mal noté mon commentaire, j'ai sûrement dû encore mal m'exprimer.
[^] # Re: Noyau NT
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Effectivement je n’avais pas compris ton intervention (mais n’avais pas moinsé, juste ignoré superbement). ;-)
Maintenant je comprends mieux ta remarque !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Noyau NT
Posté par Shunesburg69 . Évalué à 0.
Pardon, j'ai fait une grave erreur que je rectifie ici car je peux plus modifier mon commentaire.
C'est noyau GNU/Linux que je voulais dire, je suis impardonnable et ingrats envers nos amis de GNU.
Mea culpa.
[^] # Re: Noyau NT
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
par contre non, il n’y a pas de noyau GNU/Linux. GNU et l’environnement, Linux le noyau, et Linux n’est pas un projet GNU (et certains se sentiront insultés d’une telle confusion) ;-).
Tu peux parler d’une distro GNU/Linux, mais pas d’un noyau GNU/Linux. ;-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Noyau NT
Posté par Shunesburg69 . Évalué à 1.
Ah bon ?
Je croyais que les librairies GNU faisaient partie intégrante du noyau.
# réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -10.
Pourquoi tout reprendre de zéro ? Pourquoi ne pas faire comme google et android ? Un linux et ses drivers, et un userland maison ?
Comment croire qu'un tel projet sorte un jour du niveau jouet ? ils doivent passer leur temps à courir derrière le support matériel.
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par guildem . Évalué à 10.
Peut-être parce que la finalité recherchée, c'est la compatibilité avec les binaires Windows, et non l'interface utilisateur ?
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -2.
Oui, justement, c'est inutile de recoder la gestion du hardware pour ça, juste ajouter des api utilisateurs.
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par guildem . Évalué à 10.
Bah non, pour faire fonctionner directement IE, Photoshop, 3D Studio, le pilote NVidia, ….. implémenter l'ensemble du noyau NT est une solution. Et donc tout ce qui va avec, dont la gestion du hardware.
[^] # Re: réinventer la roue ?
Posté par lolop (site web personnel) . Évalué à 10.
Ils n'ont peut-être pas que les API utilisateurs… est-ce que les pilotes retrouvent l'API système Windows ?
Si oui ça pourrait permettre de continuer à faire fonctionner de vieux machins qui sont basés là dessus, genre gros matériel connecté au PC, avec driver proprio & Co plus maintenu.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: réinventer la roue ?
Posté par karteum59 . Évalué à 10. Dernière modification le 12 mars 2016 à 20:42.
Ce que tu dis là est exactement ce que fait le projet Wine (qui à ma connaissance collabore pas mal avec ReactOS, il ne faut pas les voir comme concurrents mais complémentaires). En revanche, ReactOS pourra normalement utiliser les drivers (binaires) Windows, ce qui peut être bien pratique pour faire fonctionner du matériel qui n'est supporté que sous cet OS.
J'ignore dans quelle mesure il aurait été possible que ReactOS parte d'une base de code Linux et le modifie pour intégrer/supporter l'API noyau/driver de Windows (ce qui aurait peut-être accéléré le développement initial), mais cela dit 1°/ peut-être que ReactOS intègre déjà du code de Linux/BSD (e.g. pour le support de ext4 discuté ici), 2°/ peut-être que les développeurs souhaitent juste se faire plaisir sans avoir l'objectif de conquérir le monde… (un peu comme Linux au début, d'ailleurs :)
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -9.
Il existe déjà le ndiswrapper pour les drivers windows sous linux, il me semble. Ajouter une couche de compatibilité dans Linux pour des drivers windows, doit être plus simple que de recoder un OS de zéro !
De mon point de vue, on dirait un bon gros syndrome NIH.
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par Albert_ . Évalué à 6.
Il y a des matos qui ont besoin de drivers pour des versions anterieurs de windows, qui ne seront jamais au grand jamais upgrader (la boite ne voulant pas le faire pour vendre la derniere version a XXXX gazillions d'euros, la boite a ete rachete par une autre qui a arrete cette branche, la boite a disparu de la surface de la terre…). Un projet comme cela pourrait permettre de resoudre cela.
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -10.
Avant de me moinser, il faudrait lire ce que j'écris… et essayer de comprendre.
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par Prosper . Évalué à 10.
Comprendre ce qu'est ndiswrapper aussi…
Comme son nom l'indique, ndiswrapper est limité aux drivers d'interfaces réseaux compatible NDIS et c'est tout.
[^] # Re: réinventer la roue ?
Posté par Albert_ . Évalué à 3.
Je n'ai pas "moinsser" j'ai repondu et je pense que tu pourrais aussi appliquer ta critique a toi meme.
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -4.
Je parle de créer une couche de compatibilité entre drivers windows et Linux, et tu me parles de "des matos qui ont besoin de drivers pour des versions anterieurs de windows, qui ne seront jamais au grand jamais upgrader", tu me reproches de vouloir réécrire des drivers ! Et tu t'étonnes que je râle ?
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par rewind (Mastodon) . Évalué à 6.
Au lieu de râler, lis ce qui est écrit. Le but de ReactOS, c'est de faire fonctionner à la fois les applis native Windows mais également de pouvoir utiliser les drivers fournis par les constructeurs. Donc ceux qui ont du matériel avec des vieux drivers pourraient vouloir utiliser les dits-drivers avec ReactOS de manière à pouvoir continuer à utiliser leur matériel (et aussi accessoirement les applis tout aussi vieilles qui permettent de gérer le matériel).
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Je sais, c'est même l'origine du fil de commentaire, et j'en suis l'auteur : https://linuxfr.org/news/reactos-0-4-0#comment-1647748
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par Albert_ . Évalué à 6.
Ce que tu suggeres ne fonctionne pas. Cela a ete tente et abandonne. La solution reactos est probablement plus adapte a cette problematique.
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -2.
Tu as des sources ?
Toujours bizarre de recevoir des [-], alors que c'est l'autre personne qui n’essayait même pas de comprendre.
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par Albert_ . Évalué à 2.
Que cela ne fonctionne pas? Pose toi la question de pourquoi les drivers wifi n'utilisent cela que en dernier recours et prefere developper une version native? Je soupconne qu'il doit y avoir des raisons valables derriere ce choix…
En ce qui concerne les moinssages je suis d'accord avec toi. Ce dont tu parles est totalement dans le sujet du journal donc pertinent de ce point de vu la. J'ai deja fait remarquer ce genre d'incongruite.
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Avoir un drivers GPL, par exemple ? Gérer des fonctionnalités nouvelles, comme la gestion d'énergie plus fine ?
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par Albert_ . Évalué à 4.
Quel interet pour Intel, par exemple, de faire cela? Zip nada.
[^] # Re: réinventer la roue ?
Posté par pasBill pasGates . Évalué à 9.
Moi ce que je ne comprends c'est la partie "continuer à utiliser leur matériel".
Leur Windows XP a explosé le jour ou le support s'est arreté ?
Parce que soyons un peu réaliste, il va encore falloir des années à ReactOS pour arriver à maturité vu la vitesse à laquelle il a avancé ces dernières années.
Imaginons que le code de ReactOS soit au même niveau de maturité que XP en 2020 (perso j'en doutes…), qui va s'occuper de la maintenance, support, … de ces systèmes ReactOS ? Il va falloir que des gens aient suffisament confiance dans ce nouvel OS et se lancent, que des gens soient formés, etc… cela prend quelque années en plus comme on l'a vu avec Linux. Résultat, personne ne sera prèt à prendre en charge des systèmes avant genre 2023-25.
On va dire qu'à ce moment là bcp des client potentiels se seront barrés sur des systèmes plus modernes à mon avis.
ReactOS est très sympa, mais je ne pense pas qu'il va résoudre ce problème vu ou il en est.
[^] # Re: réinventer la roue ?
Posté par Albert_ . Évalué à 2.
Tu as deja essaye d'installer win XP sur un ordi recent?
J'ai comme un soupcon que cela ne va pas fonctionner des masses.
[^] # Re:réinventerla roue ?
Posté par Juke (site web personnel) . Évalué à 3.
Pourquoi ?
[^] # Re:réinventerla roue ?
Posté par dinomasque . Évalué à 5.
Un cas concret : mes parents on renouvellé leur ordinateur portable vieux de plus de 10 ans. Ils ont voulu brancher leur imprimante sur le nouveau avec Windows 8 et patatras : imprimante plus reconnue. Et pourtant la dite imprimante n'est pas vieille du tout.
Quand bien même le nouvel ordi serai compatible Windows XP, ils n'ont aucun moyen légal de l'installer puisqu'il n'est plus vendue et qu'ils avaient une licence OEM non transférable (et pas de CD d'installation de toute façon).
C'est dans des cas comme celui là qu'une alternative au Windows du moment est précieuse.
nb: finalement en bidouillant j'ai réussi à installer un driver fait pour Windows 7 qui a fait fonctionné l'imprimante après mille bidouilles.
BeOS le faisait il y a 20 ans !
[^] # Re:réinventerla roue ?
Posté par whity . Évalué à 3.
Sur la théorie, tu as raison.
Dans la pratique, ReactOS n’est pas une solution aujourd’hui utilisable pour le quidam moyen. Et pour des raisons évoquées ailleurs dans ces commentaires, elle ne le sera vraisemblablement jamais.
Du coup, je dirais bien que la solution au problème d’imprimante de tes parents, c’est de remplacer leur windows par un linux, qui a une bien meilleure compatibilité avec les anciens matériels :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re:réinventerla roue ?
Posté par xcomcmdr . Évalué à 0. Dernière modification le 16 mars 2016 à 20:20.
Sproutch !
Putain mon
caféchocolat au lait, merdeuh !Doucement avec les blagues ! C'est vrai quoi, prévenez au moins avant de poser une bombe ! :/
Bref, perso je dois pas vivre dans la même réalité.
Il y a des milliers de pilotes pour du vieux matériel rien que pour XP (bah oui, 15 ans de vie tout de même… Et encore 8% de part de marché aujourd'hui…).
Et j'ai pas mal de cas où le pilote Windows > XP ET Linux n'existe tout simplement pas (ou n'est pas utilisable) pour le matériel utilisé. Des GeForce 2 (sous Linux, il faut se cantonner à une veille version de X), des 3DFX Voodoo 2 (driver X inutilisable, et le pilote pour XP est un pilote tiers dispo sur 3dfxzone.it ), des cartes ISA pour scanners ou pour le son, des imprimantes, des chipsets VIA, des IGP SiS, etc, etc, etc…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re:réinventerla roue ?
Posté par barmic . Évalué à 5.
Si tu as un support de cette imprimante sous linux, c'est une vraie option d'utiliser un RPi et de partager l'imprimante par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re:réinventerla roue ?
Posté par BAud (site web personnel) . Évalué à 4.
ah tiens, tu m'as effectivement fait penser à une utilisation pratique du RPi : ajouter la fonction wifi à une imprimante qui ne l'aurait pas… _o/
Pas de de doute que beaucoup de constructeurs vont se ruer dessus pour mettre en avantage leur collaboration à CUPS pour améliorer la gestion de leur imprimante sous Linux (et sous Mac).
[^] # Re:réinventerla roue ?
Posté par ckiller . Évalué à 1.
par curiosité, c'est quelle modèle d'imprimante ?
[^] # Re:réinventerla roue ?
Posté par dinomasque . Évalué à 2.
Une Canon, je ne me souviens plus du modèle.
BeOS le faisait il y a 20 ans !
[^] # Toutes les marques ne sont pas égales
Posté par Arthur Accroc . Évalué à 10.
C’est bizarre, je ne suis pas étonné.
J’en connais d’autres qui ont eu du matériel Canon (notamment un scanner haut de gamme avec chargeur automatique).
Pour résumer, pour un pilote Linux, tu peux aller te faire voir (ils ne communiquent pas les spécifications et trop de travail peut être confié au pilote pour que quelqu’un puisse raisonnablement en faire un par rétro-ingénierie) ; pour un pilote pour une nouvelle version de Windows alors que le modèle n’est plus fabriqué, tu peux aller te faire voir aussi.
Si tu veux utiliser ton périphérique sous Linux ou sous une future version de Windows, le plus simple est… d’acheter une autre marque !
Cela dit, ce n’est pas la seule marque à avoir ce type de comportement. J’ai vu le cas d’un contrôleur RAID Adaptec acheté à l’époque de Windows NT 4. Un peu après, Adaptec a racheté un fabricant de contrôleurs RAID plus performants et a arrêté les modèles qu’ils fabriquaient avant. Les pigeons qui en ont acheté ont pu aller se faire voir aussi : quand le Service Pack 3 est sorti, le pilote n’était pas compatible avec et il n’y en a pas eu de nouvelle version pour autant (et là, il ne s’agissait que de continuer le support pour le système de l’époque où il a été acheté, et pour un produit professionnel).
Moralité : prendre une marque qui facilite le support sous Linux donne au moins de bonnes chances de pouvoir utiliser son périphérique sous Linux. Il y a aussi d’assez bonnes chances qu’une marque qui fait ce genre d’efforts en fasse aussi pour les acheteurs d’anciens modèles qui sont sous Windows. C’est le choix de satisfaire l’acheteur en espérant le fidéliser pour ses achats ultérieurs, plutôt que de l’obliger à changer de matériel tout de suite en espérant qu’il soit assez bête pour racheter la même marque.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Toutes les marques ne sont pas égales
Posté par ariasuni . Évalué à 4.
J’avais une imprimante HP. Elle n’avait visiblement pas de pilotes téléchargeables pour Windows Vista ou 7. Les instructions que j’ai pu trouver sur internet me disait qu’il y avait déjà un pilote dans l’OS, ce qui n’était pas le cas.
Sous Ubuntu (j’utilisais ça à l’époque), tout a marché tout de suite sans rien à installer.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Toutes les marques ne sont pas égales
Posté par Arthur Accroc . Évalué à 2.
Peut-être ont-ils trop compté sur Microsoft pour écrire le pilote.
Ou peut-être le raisonnement est-il que si les gens ont payé un nouveau Windows plus lourd, il peuvent bien payer une nouvelle imprimante…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re:réinventerla roue ?
Posté par Albert_ . Évalué à 2.
Les drivers…
[^] # Re: réinventer la roue ?
Posté par pasBill pasGates . Évalué à 1.
Pourquoi ? Par manque de driver ?
Ils vont apparaitre de manière totalement magique les drivers pour ReactOS ? Evidemment que non, un volontaire va devoir les écrire… et il pourrait tout aussi bien les écrire pour XP.
[^] # Re: réinventer la roue ?
Posté par Albert_ . Évalué à -1.
Oui en effet mais bon personne n'a les sources de XP et XP est plus troue que un emental bouffe par des souris enrage mais bon comme d'hab je vois pas pourquoi tu critiques. Tu devrais etre content c'est du windows qu'ils font mais non tu dois critiquer a croire que tout ce qui peut s'apparenter a du logiciel libre te fous des boutons…
[^] # Re:réinventerla roue ?
Posté par Juke (site web personnel) . Évalué à 3.
Où critique t-il ?
[^] # Re: réinventer la roue ?
Posté par pasBill pasGates . Évalué à 4.
a) Faut avoir les sources de XP pour écrire des drivers ? J'étais pas au courant
b) Et comme ça par magie le ReactOS auquel personne n'a fait attention au niveau sécurité va se retrouver parfait sans trou ? T'as un humour décapant…
c) Je n'ai critiqué ReactOS nulle part, c'est ton imagination débordante comme d'hab, ce que je critiques c'est l'idée de l'utiliser comme plateforme pour des matos spécialisés en remplacement de XP, c'est une idée farfelue est j'explique clairement pourquoi.
[^] # Re: réinventer la roue ?
Posté par BAud (site web personnel) . Évalué à 3.
attaque gratuite : pour XP, c'est avéré que c'est troué et plus tenu à jour, pour ReactOS tu as vu passer des failles ou c'est juste une supposition que comme c'est un logiciel, il y en a forcément ?
bah si, dans ton b) :D
[^] # Re: réinventer la roue ?
Posté par pasBill pasGates . Évalué à 6.
C'est une supposition basée sur 15 ans d'expérience dans le domaine. Il n'y a jamais eu dans l'histoire des projets de cette taille sans failles, spécialement lorsque il n'y a pas de spécalistes sécurité dédiés sur le projet.
Ben non justement, ce n'est pas une critique, simplement un constat. Pas de jugement sur le fait qu'ils fassent un bon ou mauvais boulot. C'est la vie dans le développement software, les projets ont besoin de temps et d'efforts pour mûrir.
[^] # Re: réinventer la roue ?
Posté par BAud (site web personnel) . Évalué à 1.
ok, tu reconnais que pour XP c'est avéré, que c'est inévitable pour un autre projet.
oui, je reconnais ta retenue sur le sujet. C'est bien que presque 20 ans en sécu ne t'aient pas laissé aigri, je ne suis pas persuadé que la conclusion que tout logiciel est faillible et que cela soit inéluctable ne soit pas très déprimant :/
Mon commentaire était juste une boutade, nous connaissant bien au travers de nos échanges sur LinuxFr.org, je savais que tu saurais rester mesuré dans ta réponse, ce que tu as fait.
trop de chefs de projets, pas assez d'architectes :-) le libre avec le release often, release early permet de faire partager à plus de monde ce qui se passe bien (ou des régressions à prendre en compte au plus tôt, un jour le cycle en V va mourir, je ne dois pas être le seul à l'espérer…).
[^] # Re: réinventer la roue ?
Posté par xcomcmdr . Évalué à 4.
J'avais compris que les pilotes étaient / allaient être compatibles, vu que l'un des buts de ReactOS est la compatibilité binaire avec Windows.
Certes, faut voir quelle "génération" de pilote est visée (celle de "XP", "Seven" ?), mais j'imagine qu'à terme ce sera possible d'utiliser des pilotes Windows.
Ou j'ai tout faux ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: réinventer la roue ?
Posté par whity . Évalué à 2.
Ça pose des problèmes difficilement solubles.
Par exemple, la pile audio de Vista est totalement différente de celle d’XP, et c’est la raison pour laquelle les pilotes sont différents (le pilote audio pour xp ne marche pas du tout sous vista). Je ne suis pas sûr qu’on puisse vraiment faire cohabiter les deux piles.
L’autre point, c’est que si Microsoft a changé d’approche, ce n’est pas uniquement pour se faire plaisir, mais souvent parce que l’ancienne approche ne fonctionnait pas correctement / ne fournissait pas le service voulu (dans le cas de l’audio : impossible d’avoir un volume par application, par exemple) ou posait des problèmes de sécurité / plantage (plantage complet du système en cas de défaillance d’un pilote wifi, par exemple).
Je ne sais pas quelle est la stratégie de ReactOS à ce niveau. En clair, si le noyau visé est le 5 ou le 6, ou un mix des deux, ce qui me semble extrêmement difficile à maintenir.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: réinventer la roue ?
Posté par pasBill pasGates . Évalué à 6.
Ben oui mais si l'idée est d'utiliser ReactOS sur des matos ou XP n'a pas de drivers… ben ils pourront pas réutiliser les drivers de XP vu qu'il n'y en a pas justement.
Et donc il faudra les écrire ces drivers pour ces entreprises qui veulent bouger leurs systèmes, à ce moment, ben autant utiliser ces drivers sur XP qui a eu 15 ans pour mûrir plutôt qu'un OS tout récent et immature.
[^] # Re: réinventer la roue ?
Posté par ZeroHeure . Évalué à 2.
Tu as deja essaye d'installer ReactOS sur un ordi recent?
J'ai comme un soupcon que cela ne va pas fonctionner des masses.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: réinventer la roue ?
Posté par karteum59 . Évalué à 6.
ça se pourrait bien vu que les failles de sécurité ne sont/seront plus corrigées…
Après, si on le fait tourner dans une VM (avec un PCI/USB-passthrough pour les devices qui n'ont pas de support sous Linux), il n'est pas forcément nécessaire d'avoir exactement le même niveau de mâturité
Moi aussi. D'un côté on a un OS commercial développé par une armée de professionnels payés pour ça, et de l'autre quelques passionnés. Je trouve que c'est déjà pas mal d'en être arrivé là où ils sont !
En même temps comme je le disais plus haut, le but des devs est peut-être juste de se faire plaisir en relevant le défi de faire le mieux possible, et pas de conquérir le monde ou choper un max de "clients potentiels"…
[^] # Re: réinventer la roue ?
Posté par pasBill pasGates . Évalué à 3.
Ben si c'est ça qui les inquiète, ils ne vont surement pas utiliser ReactOS avant 10 ans… Faut être sérieux, il n'y a absolument personne qui a passé même une seconde à regarder la sécurité de ce système vu qu'il est encore nascent, tous les bugs restent encore à trouver là oû XP a eu 15 ans de recherche de failles.
Ben…. pourquoi ne pas faire tourner XP dans cette VM alors ?
Tout à fait, je ne remets absolument pas en cause le projet, je trouves ça très sympa, mais simplement je doutes que l'aspect commercial proposé içi fonctionne.
C'est aussi ce que je pense, et c'est très bien.
[^] # Re: réinventer la roue ?
Posté par barmic . Évalué à 3.
De quel aspect commercial parle tu ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: réinventer la roue ?
Posté par pasBill pasGates . Évalué à 2.
L'idée citée plus haut d'utiliser ReactOS comme remplacement de XP pour pouvoir continuer a utiliser du matos specialisé avec des drivers qui ne tournent plus sur les nouvelles versions de Windows.
"Commercialiser" car il faudrait des sociétés qui offrent le support pour.
[^] # Re: réinventer la roue ?
Posté par Albert_ . Évalué à -1.
J'ose esperer que tu as des preuves de ce que tu avances comme quoi ReactOS a copie Redmond y compris dans sa facon de developper XP…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: réinventer la roue ?
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
En fait ça existe. Le projet Longene vise bien à unifier les architectures Windows et Linux en intégrant directement dans le noyau Linux les appels systèmes du noyau NT (et qui fonde son travail évidemment sur les efforts de Wine et ReactOS).
Enfin, existe ou existait je ne sais pas… Le site web est toujours en ligne mais il n'y a pas eu de publication depuis 2014. En fait ça n'est pas nécessairement inquiétant puisque le projet avance discrètement depuis déjà 10 ans sans faire beaucoup de bruit (je connais des projets actifs qui font encore moins de bruit), mais ce qui minquiète plus est que le dépôt git documenté (
git://git.longene.org/unifiedkernel.git
) ne répond plus, et que le gitweb non-plus, et que le mailman s'est fait la malle (haha) lui-aussi, tout comme le bugzilla… Cependant le forum officiel en chinois est toujours actif mais je ne saurais pas dire de quoi ils parlent !ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: réinventer la roue ?
Posté par barmic . Évalué à 9.
D'après google translate, ils se demandent si le projet est mort ou pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: réinventer la roue ?
Posté par ZeroHeure . Évalué à 3.
Il y a une copie du source de la dernière version 1.0-rc2 sur Kde-apps et un miroir sur Github
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: réinventer la roue ?
Posté par rakoo (site web personnel) . Évalué à 10.
En tant que développeur, l'un des intérêts que je vois c'est de tester la compatibilité d'une application avec Windows, ou en tout cas d'en avoir une idée fiable, sans avoir besoin de payer une licence et de pourrir son ordinateur avec tout plein de mouchards.
[^] # Re: réinventer la roue ?
Posté par thaddeus (site web personnel) . Évalué à 10.
J'ai cru comprendre que les développeurs appréciaient Windows, même si c'est difficile à imaginer pour nous. Il est donc naturel pour eux de refaire un Windows, pas de personnaliser Linux.
[^] # Re: réinventer la roue ?
Posté par Albert_ . Évalué à -1.
Tu as tout a fait raison mais il y semblerait que certains devs windows n'apprecient pas trop l'intrusion windows 10 mais bon c'est peut etre une minorite insignifiante.
[^] # Re: réinventer la roue ?
Posté par Maclag . Évalué à 9.
Si je comprends ce que tu veux dire, Wine serait la voie à suivre et ReactOS serait inutile.
Alors pense aux cas de figure suivants:
-une institution sans le sou voit la fin du support de Windows N ; si ReactOS avait été "prêt", ils auraient pu éviter une migration coûteuse et/ou douloureuse
-un dev libriste souhaite rendre son appli multiplateforme mais n'a pas de licence Windows: il peut développer sur ReactOS (je suppose que la compatibilité est dans les 2 sens)
-j'ai un super gadget à la mode, mais le logiciel pour le régler/activer/mettre à jour ne marche que sous Windows ou Mac, et vient avec un pilote matériel: ouf! ReactOS le rend utilisable!
-ma grand-mère veut récupérer un ordinosaure, mais n'a jamais connu que Windows, elle habite trop loin pour une formation Linux et ses amis jouent au bridge en ligne avec un logiciel Windows: la solution est toute trouvée!
[^] # Re: réinventer la roue ?
Posté par claudex . Évalué à 5.
À part le coup du pilote, je ne vois pas pourquoi wine ne pourrait pas répondre à ses cas là (il y a aussi un explorer et un bureau windows)
À part ça, je trouve que reactos est une bonne chose. Un exemple d'utilisation que j'avais entendu était pour le chercheurs en sécurité, ils peuvent facilement introduire de nouvelle API ou limitation et voir ce que ça donne pour protéger le système.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: réinventer la roue ?
Posté par pizaninja . Évalué à 3.
Dans le monde des DevOps d'aujourd'hui, pour tester des applis sous windows à partir d'un iso officiel de MS, il existe packer+vagrant, capable d'installer un windows 7 et au dela en VM en moins d'1h.
Reactivation automatisable de la licence pour 10 jours de plus (4 fois maxi) en ligne de commande:
[^] # Re: réinventer la roue ?
Posté par Grumph . Évalué à 9.
Dans l'industrie en général, il y a beaucoup de logiciels propriétaires avec pilotes pour faire fonctionner des machines, sondes, ou autres trucs excessivement chers qui ne tournent que sous windows. Pire encore, le plus souvent tout ça ne supporte pas plus que windows XP.
Ces périphériques répondent à des besoins très spécifiques qui n'ont pas d'équivalent sur le marché. Redévelopper des pilotes pour des windows récents ou pour linux, ou redévelopper des machines similaires à jour coûteraient des sommes faramineuses et beaucoup de temps, pour cause de certifications à passer par exemple.
À mon boulot par exemple, il y a encore beaucoup de PC sous windows XP par manque de choix, malgré l'absence de support et les problèmes de sécurité.
ReactOS permet de pallier à cette obsolescence forcée via l'utilisation d'un système libre, là où une simple surcouche logicielle ne suffirait pas.
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -2.
La surcouche en question pourrait très bien être un module noyau linux. En quoi recoder la gestion de tache, des disques, du réseau a un quelconque intérêt ?
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par lolop (site web personnel) . Évalué à 5.
Définir "Intérêt".
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -2.
Poursuivre le but initial de faire tourner "out of the box", les applications et drivers spécifiques windows.
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par lolop (site web personnel) . Évalué à 5.
Pour faire tourner des drivers Windows "out of the box", il doit y avoir besoin d'être plutôt très prêt de l'API système de Windows, et je ne suis pas sûr que l'organisation du noyau dans Linux s'y prête.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: réinventer la roue ?
Posté par barmic . Évalué à 10.
À mon avis tu t'avance pas mal. L'organisation même des noyau peu être très différent et ta surcouche risque d'être pas mal intrusive dans linux. Tu n'a quasiment aucune chance d'être intégré dans l'arbre des sources du noyau et survivre en dehors de la LKML c'est une gageur (regarde les OpenVZ et autre grsecurity).
Bref le développement dans le noyau ou en tout cas pour le noyau linux est très contraignant et ce n'est pas forcément une gynastique à la quelle les développeurs de ReactOS veulent se plier.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: réinventer la roue ?
Posté par Michaël (site web personnel) . Évalué à 5.
J'ajouterai que les noyaux utilisent parfois des représentations tellement différentes qu'il devient très difficile d'adapter le support d'une même fonction entre deux noyaux. C'est par exemple le cas des systèmes de fichiers sous Linux et FreeBSD, et explique l'interopérabilité plutôt limitée entre Linux et UFS d'une part et FreeBSD et extfs d'autre part. (Du moins historiquement, je ne suis peut-être pas très à jour, tout mes Linux tournent dans une VirtualBox.)
[^] # Re: réinventer la roue ?
Posté par Tonton Th (Mastodon) . Évalué à 1.
Encore faut-il avoir la documentation du matériel concerné…
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -5.
Je crois que tu n'a rien compris au sujet. Il est évidement question d'une couche de compatibilité avec les drivers windows, sinon, cela n'aurait aucun sens.
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par reynum (site web personnel) . Évalué à 9.
L'objectif étant d'être compatible Windows; Ils utiliseront les drivers pour cet OS. Et si je ne m'abuse c'est pas ce qui manque.
kentoc'h mervel eget bezan saotred
[^] # Re: réinventer la roue ?
Posté par lolop (site web personnel) . Évalué à 1.
S'ils restent avec une compatibilité Windows XP, ça pourrait commencer à manquer avec les matériels récents.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: réinventer la roue ?
Posté par dinomasque . Évalué à 10.
La vraie réponse : parceque les développeurs peuvent le faire et en ont envie.
BeOS le faisait il y a 20 ans !
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -6.
C'est ce que je comprends le mieux, alors pourquoi se trouver d'autres raisons ?
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par xcomcmdr . Évalué à 6.
Mais t'as même pas demandé au développeurs, t'as juste fait ton caca sur linuxfr "OHHH NIH", "OH YAKAFOKON RECODER WINE!!1" et chacun a tenté de donner sa réponse (hint : 99% du temps des commentateurs sur linuxfr ne sont pas les auteurs du projet dont la dépêche parle).
Envoie leur un mail et fous nous la paix !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: réinventer la roue ?
Posté par reynum (site web personnel) . Évalué à 5.
Non mais là non !! si on ne peut même plus troller tranquillement sur DLFP, où va t on ?
kentoc'h mervel eget bezan saotred
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -8.
Si on regarde leur but affiché, cela ressemble aux syndromes NIH, avec une perte de temps et d'énergie énorme à la clef.
Si le but est de se faire plaisir, ce n'est plus vraiment du NIH, mais un jeu. Réinventer la roue est amusant, mais pas utile. Si le but est de supporter les drivers windows, par rapport à Wine qui supporte les applications windows, il y a des tonnes de techniques plus simple que de réécrire un OS !
"La première sécurité est la liberté"
[^] # Re: réinventer la roue ?
Posté par xcomcmdr . Évalué à 5. Dernière modification le 15 mars 2016 à 09:56.
C'est vraiment obligatoire de devoir justifier ReactOS pour toi ?!
Et peut-être que leur but, c'est d'avoir un Windows libre.
Bref, plutôt que de parler dans le vide, pose leur la question directement…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: réinventer la roue ?
Posté par pasBill pasGates . Évalué à 9.
Moi mon point de vue est très différent : Peut-être qu'ils trouvent simplement le design du système à leur goût et veulent un système de ce type qu'ils contrôlent de bout en bout et peuvent modifier.
[^] # Re: réinventer la roue ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Linux aussi était un hobby au début.
"La première sécurité est la liberté"
# Et la réciproque ?
Posté par Gabbro . Évalué à 10.
Bonjour,
le but est donc de faire tourner des binaires windows sous ReactOS.
En tant que développeur, sous linux, je me demandais si la réciproque était vrai : si je compile un logiciel sous ReactOS, est-ce que les windowsien pourront exécuter le binaire généré ? Parce que ça aurait un côté à la fois assez fun et pratique.
[^] # Re: Et la réciproque ?
Posté par macadoum . Évalué à -10.
Je crois que ce n'est pas ( ne sera jamais ?) possible.
[^] # Re: Et la réciproque ?
Posté par ʭ ☯ . Évalué à 10.
Bien sûr, ce n'est pas le système d'exploitation qui génère les binaires; Tu peux déjà contruire avec mingw un binaire windows sous linux…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Et la réciproque ?
Posté par Shunesburg69 . Évalué à 7.
Oui, c'était l'un des but fixer par ReactOS pouvoir interchanger les dll et les applis entre windows et ReactOS.
# Stabilité
Posté par thaddeus (site web personnel) . Évalué à 10.
D'après mon expérience personnelle, cette version est beaucoup plus stable que la précédente. Cette dernière était quasiment inutilisable chez moi, mais c'est peut-être parce-que j'ai un vieux PC avec peu de RAM.
Avec la version 0.4.0, je n'ai pour l'instant pas eu de plantage, et j'ai pu jouer plusieurs heures à mon jeu Windows favori. Même si ce jeu est une antiquité sans 3D, c'est quand même une bonne performance. les développeurs ont fait du beau boulot et je les en remercie.
[^] # Re: Stabilité
Posté par ʭ ☯ . Évalué à 3.
Quel matériel tu utilises? Pour avoir une idée de ce qui pourrait marcher…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Stabilité
Posté par thaddeus (site web personnel) . Évalué à 3.
J'ai un portable Acer Aspire, processeur Celeron à 1,8 GHz, 1 Go de RAM. Mon OS est Debian testing, et je fais tourner ReactOS dans VirtualBox. C'est fluide, je n'ai pas observé de ralentissement perceptible.
[^] # Re: Stabilité
Posté par ʭ ☯ . Évalué à 4.
Ah, j'avais compris que tu ne virtualisais pas…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Stabilité
Posté par Shunesburg69 . Évalué à 6.
Normalement on peut faire tourner ReactOS sur de très vielle machine avec peu de RAM, mais en installation directe pas en VM. Les pilotes pour VirtualBox ont été introduit dans la 0.4, c'est sûrement pour ça que c'est plus stable pour toi aujourd'hui.
[^] # Re: Stabilité
Posté par thaddeus (site web personnel) . Évalué à 2.
Tu as certainement raison. J'aurais dû préciser que j'avais testé dans une VM, mais cela me paraissait évident. Je me rends compte maintenant que cela ne l'était pas.
[^] # Re: Stabilité
Posté par Shunesburg69 . Évalué à 1. Dernière modification le 15 mars 2016 à 22:47.
Non t'as pas à t'excuser, car il y a encore pas si longtemps ça tournait quasiment que sur VM mais sans tous les drivers de reconnus, c'est depuis peu qu'on peut le tester sur du vrai matériel. C'est comme ça que j'ai compris d'ailleurs.
# Développement windows
Posté par Goffi (site web personnel, Mastodon) . Évalué à 9.
Content de voir que ça avance toujours (j'avais fait une dépêche sur le sujet il y a bientôt 7 ans (wow, ça ne me semblait pas aussi vieux).
Je ne suivais plus trop l'actualité de ce projet, mais il y a un domaine où ça pourrait m'intéresser fortement, c'est pour le développement de version Windows de mes logiciels. Il y a déjà eu des expériences de ce type ? Je suis encore moins l'actualité Windows, est-ce que ça aurait du sens aujourd'hui de compiler/tester dessus alors qu'il y a des Windows 7, 8 et 10 ?
[^] # Re: Développement windows
Posté par Shunesburg69 . Évalué à 1.
Normalement, il y a tout ce qu'il faut pour développer dessus (Cmake, GCC…) par contre je sais pas si c'est encore assez stable pour ça.
# libvirt
Posté par claudex . Évalué à 3.
J'ai essayé d'installer l'ISO avec libvirt (via virt-manager) mais ça freeze dès le premier écran, il y a une configuration particulière pour faire marcher reactos avec qemu ? (Je n'ai pas trouvé l'information sur le site)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: libvirt
Posté par Renault (site web personnel) . Évalué à 2.
J'ai testé dans la même configuration que toi.
Cela gel avec le boot par défaut (en debug), si je sélectionne la première entrée de boot, le bureau est fonctionnel.
[^] # Re: libvirt
Posté par claudex . Évalué à 4.
Je ne vois pas de quelle entrée tu parle, moi c'est freezé sur
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: libvirt
Posté par Renault (site web personnel) . Évalué à 2.
Je n'ai pas ça, j'ai téléchargé le liveCD pour ma part.
[^] # Re: libvirt
Posté par claudex . Évalué à 3.
Je parle de l'installateur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: libvirt
Posté par Pierre Schweitzer (site web personnel) . Évalué à 9.
Xavier, dans ce cas là, il ne faut pas mettre de périphérique USB (laisser le contrôleur à nu). L'USB de KVM & ReactOS ne font pas bon ménage actuellement.
L'installation pourra alors se poursuivre.
[^] # Re: libvirt
Posté par claudex . Évalué à 4.
Un grand merci, ça marche.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: libvirt
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Non non, c'est bien ça : un écran bleu qui ne bouge pas, ils ont réussi à reproduire Windows à la perfection !
[^] # Re: libvirt
Posté par Shunesburg69 . Évalué à 0.
Marrant mais presque vrai ;-)
# ReacOS
Posté par zurvan . Évalué à 10. Dernière modification le 13 mars 2016 à 21:35.
Merci de désinstaller Notepad++ (que l'on voit dans une des copies d'écran, l'auteur a pourtant précisé qu'il ne voulait pas que les Réac utilisent son logiciel ;)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: ReacOS
Posté par Fabien PRORIOL . Évalué à 1.
Merci d'expliquer…
Sur le lien que tu pointe, je ne vois aucun lien avec ReacOS
[^] # Re: ReacOS
Posté par barmic . Évalué à 9.
C'est un jeu de mot entre ReactOS et réactionnaire…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ReacOS
Posté par kowalsky . Évalué à 10.
L'auteur de notepad++ a dit qu'il n'aimait pas le FN. Les Reacs quoi.
ReacOS.
Ah ah. 'culer un mouton. C'est drole 'culer un mouton !
[^] # Re: ReacOS
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Ah merci \o/, j’avais fait exprès de mettre Notepad++ dans la copie d’écran pour la boutade de faire tourner Notepad++ sur un « OS de Réactionnaire ». :p
ce commentaire est sous licence cc by 4 et précédentes
# Pile USB
Posté par freejeff . Évalué à 9.
Il n'y a très que très peu de périphériques USB qui sont supportés, or c'est la majeur partie de mes utilisations d'une machine virtuelle windows xp. Ça serait vraiment sympa qu'ils arrivent à ce stade car cela profiterait aussi à wine et autoriserait l'utilisation de plein de périphériques, imprimantes, scanner, matos spécifiques … qui posent la majeur partie des renoncement à linux autour de moi (hors jeux). Donc longue vie à ce projet ! Et bossez sur la pile USB !
[^] # Re: Pile USB
Posté par Shunesburg69 . Évalué à 1. Dernière modification le 23 mars 2016 à 12:13.
C'est en cours et déjà prometteur, on aura sûrement de bonnes surprises quand sortira la version 0.5 mais d'ici là, on sera peut-être plus là pour le voir vu le temps de développement de l'OS ;-) (20 ans et toujours en version alpha)
[^] # Re: Pile USB
Posté par freejeff . Évalué à 3.
Ha bon ?
Je n'avais pas vu grand chose ni chez eux ni chez wine, si tu as des détails, je suis preneur !
[^] # Re: Pile USB
Posté par Shunesburg69 . Évalué à 2. Dernière modification le 02 avril 2016 à 15:37.
Chez Wine depuis la version 1.2 (si je me trompe pas), ils ont implantés "le support de l'USB", c'est à dire un semblant de pile USB, depuis on voit de temps en temps (pas souvent) dans leurs commentaires de version des améliorations ou nouveautés concernant des périphériques USB ou fonctionnalités USB implantées. Comme ReactOS est basé pas mal sur les librairies Wine, ils ont pas mal avancé de ce côté, en grattant à droite à gauche sur leur forum et les quelques docs que j'ai pu voir, ils ont bien implémenté une pile USB (apparemment en test depuis la 0.3) mais ils sont très avare en détails et il faut souvent lire entre les lignes, en tout cas le "Support USB" comme ils l'appellent est officiel depuis la version 0.4 qui est l'objet de cette dépêche.
# Aperçu
Posté par MTux . Évalué à 5. Dernière modification le 17 mars 2016 à 10:38.
Je l'ai installé dans une VM pour voir et j'ai mis les outils invités Virtualbox.
A ma grande surprise ça marche le pilote vidéo est chargé je peux redimensionner à souhait ma VM (la taille du bureau s'adapte).
Installation de firefox ça marche aussi.
Je regrette qu'il n'y ait que FAT32 (pas de NTFS) et que le système soit si lent alors que d'après taskmgr (oui il existe!) l'UC et la mémoire ne sont pas du tout chargés.
# ça marche vraiment!
Posté par toctoc1 . Évalué à 4.
Bon, encouragé par vos messages, j'ai lancé ça dans une VM sur ma vieille trapanelle, un vaio tz21 avec Lubuntu dessus. J'ai accordé 900Mo de ram à ma VM et c'est quand même très utilisable.
Le gestionnaire d'applications est très bien fait. Je suis agréablement surpris!
Je cherche à lancer une app maison qui utilise .Net >4 . Là, ça risque d'être un peu sport.
Vraiment chouette.
# Et pour les virus?
Posté par seb95 (site web personnel) . Évalué à -4.
Je me demande jusqu'a ou ReactOS peut etre comparé a windows, et si il y a bien un truc qui nous manque pas de windows c'est bien les virus! Qu'en est t'il sous reactos?
[^] # Re: Et pour les virus?
Posté par xcomcmdr . Évalué à -1.
seb95 est resté bloqué en 1995.
J'ai pas eu de virus depuis Vista.
Oh wait, depuis Windows 2000 en fait.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Et pour les virus?
Posté par Albert_ . Évalué à 3.
Oui enfin au boulot je remarque que c'est absolument necessaire de mettre des anti-virus…
Et si l'on veut jouer a qui a la plus longue: je n'ai jamais eu de virus sous linux depuis 1996…
[^] # Re: Et pour les virus?
Posté par Kerro . Évalué à 5.
Si tu prends la peine de préciser une date de départ, c'est que tu as eu un virus avant ? :-)
J'ai l'impression que la bonne phrase est plutôt : « je n'ai jamais eu de virus sous linux, que j'utilise depuis 1996 »
[^] # Re: Et pour les virus?
Posté par Albert_ . Évalué à 9. Dernière modification le 25 mars 2016 à 09:00.
Ben oui avant 96 j'utilisais windows, il y avait donc un gros virus sur mon ordi mais je l'ai echange contre un cancer :)
[^] # Re: Et pour les virus?
Posté par Shunesburg69 . Évalué à 1.
Cancer d'après micorsoft mais "salut" pour nos ordinateurs perdus.
PS: D'ailleurs, je crois que quand Ballmer disait cancer, il parlait pour le portefeuille de sa société en fait.
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 3.
[mode pédant] Et ils trouvent beaucoup de virus? Parce que non, les trojan, adwares et autres toolbars ne sont pas des virus. [/mode pédant]
En tout cas, c'est une bonne question: la compatibilité des malwares windows avec reactos a-t-elle été testée? Ça peut être utile, pour ceux qui veulent jouer à les analyser sans avoir de licence windows. Ou sans pourrir leur windows, pour le coup.
[^] # Re: Et pour les virus?
Posté par Shunesburg69 . Évalué à -1.
Pour ReactOS je sais pas mais pour Wine c'est une belle légende urbaine car Wine reste quand même cloitré aux droits utilisateur restreint qui lui sont attribués.
[^] # Re: Et pour les virus?
Posté par xcomcmdr . Évalué à 3.
Et alors ?
Un programme malveillant peut faire énormément de choses sans devoir être root.
Le site officiel de Wine dit justement de faire attention :
https://wiki.winehq.org/FAQ_fr#Wine_est_compatible_avec_les_logiciels_malveillants
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Et pour les virus?
Posté par Shunesburg69 . Évalué à 1. Dernière modification le 02 avril 2016 à 16:15.
C'est vrai mais c'est pas ce que je disais.
Je n'ai pas dit que ce n'était pas possible, j'ai dit que vu les droits ce serait plus difficile, et à ce jour personne n'a fait écho d'un virus ayant infecté une machine (et je précise pas volontairement en compilant exprès un virus pour voir si c'est possible) via Wine.
[^] # Re: Et pour les virus?
Posté par seb95 (site web personnel) . Évalué à 2.
Heu non j'ai eu a dépanner un seven qui a eu plus de 20 virus, avec des trojan et autres joyeusetés…
[^] # Re: Et pour les virus?
Posté par xcomcmdr . Évalué à 3. Dernière modification le 25 mars 2016 à 15:13.
Ce qui prouve que ça dépend de l'utilisateur, pas de l'OS.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Et pour les virus?
Posté par Albert_ . Évalué à -3.
Euh tu connais un autre OS qui a des virus?
Parceque OSX et Linux en dehors de "proof of concept" je n'ai pas entendu parler.
Et les antivirus sur ces deux systemes c'est generalement pour scanner les documents MS Office. Amusant de voir qu'il faut attendre 2016 pour que MS Office n'ouvre pas les macros dans les documents de facon automatique (enfin si j'en crois une des annonces de MS sur les nouveautes de MS Office 2016).
[^] # Re: Et pour les virus?
Posté par oinkoink_daotter . Évalué à 6.
Le KeRanger de Transmission du début du mois était bien réel. Après, je ne sais pas au 21e siècle ce qu'on appelle virus.
Mais c'est typiquement ce qu'un AV devrait bloquer.
D'après Microsoft, il y a l'air d'y avoir déjà des choses depuis office 2007. Sur l'ordinateur du boulot, Office 2010, il me demande si je veux activer les macros quand il y en a. Ca a aidé (pas seul) à ne pas nous faire pourrir par dridex et locky. D'ailleurs, on a vu la dedans des fichiers word vérolés dont le texte du doc indiquait que le contenu ne pouvait pas être affiché à cause de la désactivation des macros et qui expliquait gentiment comment les activer <3.
En fait, d'après Zdnet, ce qui est mis en place dans Office 2016, c'est ce sont des moyens anti-boulet, car la fonction existe bien, mais les utilisateurs font n'imp.
Bref, comme souvent, tu fais ce que tu reproches à MS. Tu fuddes :(
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 10.
Android? En tout cas, vue la pléthore d'anti-virus qu'il semble y avoir, il est probable qu'il y ait des virus.
Ah, et android, c'est un linux, juste au cas ou.
Si tu veux un virus pour bureau, alors dis moi si ce scénario (fictif, certes) te semble si peu crédible:
Un utilisateur Debian souhaite jouer à RedEclipse. Manque de bol, la version dans les dépôts stable, backport inclus, n'est pas assez à jour pour lui, il décide donc de l'installer à partir du site officiel.
Pas de chance, le site officiel à été victime d'une attaque qui n'a pas encore été détectée, et les archives du logiciel ont été infectées (en fait, l'attaquant à simplement renommé le binaire, et fait un script shell qui lance son virus puis passe la main à l'exécutable officiel: ni vu, ni connu).
N'étant pas un bidouilleur mais l'un de ceux que l'on appelle habituellement un "utilisateur normal", il n'a jamais modifié ses fichiers de configuration, du coup le script n'a qu'à modifier le fichier ~/.profile en insérant le dossier ~/.bin au PATH (
sed -i 's/$HOME\/bin/$HOME\/.bin:$HOME\/.bin/g'
), créer le-dit dossier, y ajoutes des commandes d'authentification vérolées, et ajouter des alias correspondant (pour su, ça semble nécessaire après test, pour sudo non… triste.).Voila, à la prochaine tâche administrative faite par l'utilisateur en ligne de commande (typiquement, via sudo), le virus pourra avoir un grand contrôle sur la machine, et donc infecter les binaires principaux du système.
Comme notre utilisateur est un fan de jeux vidéos, il utilise un GPU NVidia, et préfère utiliser le pilote officiel (sous Debian, je ne peux pas lancer nombre de jeux avec le pilote nouveau). Du coup, il utilise DKMS, qui injecte le pilote NVidia dans le kernel. Le virus prend avantage de cette fonctionnalité pour infecter directement le kernel.
Voila. fin de l'histoire.
Les deux véritables difficultés au final, outre le code du virus lui-même, c'est:
1) générer un vecteur d'infection. Sous windows, pas mal de malwares sont installés à cause de logiciels qui ne sont pas récupérés sur le site officiel. Avec l'arrivées des jeux vidéo commerciaux sous linux, on risque de voir émerger des cracks, et certains pourront être vérolés (c'est un vecteur d'infection assez important sous windows).
2) l'escalade des droits. Dans ma petite histoire, l'attaquant passe par un script d'installation vérolé, et nécessite l'usage de su ou sudo. En fait, je suis bête, j'ai surestimé l'utilisateur: l'attaquant ferait certainement comme sous windows, il demanderait poliment le droit de s'exécuter avec gksu. Voire même, pas besoin, après tout, que cherchera-t-on à récupérer? De l'espace disque? Du CPU? Des données? Tout ça, sur une installation de bureau, ce ne sont pas les prérogatives de root (ou peu importe le nom de l'utilisateur avec l'uid0), l'utilisateur principal, qui installe le malware, en dispose aussi. D'ailleurs, c'est lui qui a les données… pas root.
La seule raison pour laquelle Linux et Mac OS n'étaient pas ciblés jusqu'à présent, c'est la part de marché. La technicité traditionnelle des utilisateurs linux aussi, probablement, mais ça, ça risque d'être de moins en moins d'actualité (ce qui ne veux pas dire que c'est demain "l'année du bureau linux" je ne crois pas aux révolutions. Ici, j'ignore volontairement android, je parle bien des bureaux.).
Pour voir les malware arriver sur les bureaux, il suffirait que le grand public commence à utiliser linux sur le bureau, et un frein est en train de tomber: les jeux vidéos arrivent, grâce à steam. Donc, les cracks finiront par arriver, et avec les cracks, les malwares.
[^] # Re: Et pour les virus?
Posté par ariasuni . Évalué à 0. Dernière modification le 30 mars 2016 à 03:55.
Le fait est que la plupart des logiciels installés sous GNU/Linux sont servis sous forme de paquets signés via les dépôts (ce qui protège d’attaques modifiant les paquets, dans le cas où les clés sont bien protégées). D’autre part faudrait cibler en particulier le serveur qui sert aux miroirs à s’alimenter. Y a moyen de signer les exécutables Windows également mais c’est moins contraignant je crois?
Du coup pour les gens qui n’installent pas grand chose sur leur ordinateur, le risque est moindre que sur Windows je dirais. Par contre pour les gens qui installent des trucs à la main, ça peut être plus facile. Remarque, faut quand même marquer le fichier comme exécutable, ce qui offre une (maigre) protection supplémentaire.
Peut-être qu’en faisant des logiciels à base d’AppImages avec restriction d’accès au système de fichier (uniquement pour accéder à des fichiers à modifier par l’application par exemple, et aux fichiers de configuration si ceux-ci ne sont pas stockés dans l’archive).
Bon après c’est vrai qu’à partir du moment où tu peux exécuter quelque chose sur la machine, quelque soit le système d’exploitation, on peut quand même t’emmerder pas mal. D’un autre côté, vu la diversité des distributions ça peut vite être plus compliqué — encore que cibler uniquement Ubuntu peut-être une solution. Du j’ai la sensation que c’est un peu plus compliqué sur GNU/linux (mais très loin d’être impossible).
Écrit en Bépo selon l’orthographe de 1990
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et pour les virus?
Posté par ariasuni . Évalué à 0.
Je disais simplement qu’installer des «logiciels pirates [piratés?] parce que sinon payants» est loin d’être le cas de figure le plus courant.
Bah c’est plus dur d’installer des logiciels en dehors des dépôts que de choper un exécutable sous Windows, mais c’est bien plus facile d’installer un logiciel depuis un dépôt. Y a quoi qui vient pas des dépôts après? Minecraft, les jeux installés par le biais de Steam, les logiciels livrés via AppImage, Atom, Firefox Beta/Developer (qui certes s’intègre moins bien)… Le «configure, make, make install» c’était y a longtemps ça.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 4.
Parce que l'offre logicielle commerciale à destination des particuliers est très réduite sur GNU/linux?
La plupart des logiciels crackés que j'ai pu voir, c'étaient des jeux vidéo (ah, et winzip/rar, 'toshop et nero aussi). Sans passer par un wine arrosé d'un peu de poudre verte, ou dosbox pour les plus vieux, la majorité ne passe pas sous Linux, et même pour ceux qui passent, ce n'est pas sûr qu'ils fonctionnent bien.
Tu as oublié le plugin flash, notamment. Dans son cas, l'installateur est installé par le dépôt, mais ce n'est qu'un outil intermédiaire qui va télécharger le véritable je ne sais où. Et pour l'argument comme quoi flash serait mort, c'est de la connerie: les sites qui ne requièrent pas flash pour lire une vidéo restent une minorité de mon expérience personnelle (je dirais, à peu près 16% de ceux sur lesquels je tombe).
Reste aussi le fait qu'il existe des dépôts externes: moi j'utilise les dépôts officiels de clang, et vivaldi notamment (avant vivaldi c'était celui d'opéra). Les ubuntistes utilisent manifestement assez régulièrement les ppa, et pour les utilisateurs d'arch, il semble qu'ils aient le même type de mécanisme qui permets de prendre des paquets de source moins fiable relativement aisément. En dehors des dépôts, je joue à redeclipse, donc pas le choix pour avoir une version récente sur Debian: download manuel. 3 situations ou j'utilise du logiciel externe, 3 cas d'usages différents donc: dev', web et jeux. Ça peut toucher pas mal de monde, pas vrai?
Bref, pas convaincu que les dépôts soient la panacée.
[^] # Re: Et pour les virus?
Posté par ariasuni . Évalué à 2.
Moi ça tourne plutôt autour de 100%. Youtube, Dailymotion, Vimeo, etc. sont tous passés en HTML5 (bon y’a Nico Nico Douga que j’utilise peu, et Twitch que je n’utilise pas). Bref je tombe peut-être une fois par mois où je tombe sur une vidéo illisible dans un mois. Enfin, je pense que Flash va bientôt disparaitre donc je m’inquiète pas vraiment de ce cas de figure.
D’ailleurs dans ma distribution j’utilisais un paquet qui extrait le plugiciel Flash encore maintenu de Chrome + un paquet pour faire la liason API Chrome/Firefox. Et Google est plutôt bon pour sécuriser ses serveurs, non?
Bon j’avoue que je suis pas bien au courant des usages des gens, mais sans sortir des dépôts ça peut déjà convenir à beaucoup de monde je pense.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 4.
Ah oui? Moi il me faut le plug-in pour aller dessus pourtant. Quel navigateur, quelles distro?
Sinon j'ai aussi rutube, ok, et pas mal d'autres. À savoir que dailymotion d'ailleurs m'énerve particulièrement: publicité énorme avec en plus un plug-in flash buggué à bloc… du coup j'évite autant que possible les liens daily. Je me demande ce qu'est devenu wat.tv que j'allais consulter de temps en temps d'ailleurs.
En tout cas, mon browser habituel (et ces derniers temps j'ai passé pas mal de temps sur FF) me demande flash pour dailymotion et divers autres sites. Après, je suppose que le vécu diffère selon les gens (mais pour daily, faut que tu me dises!) mais c'est justement un truc à garder à l'esprit des deux côtés d'un débat :) (on dirait d'ailleurs que j'ai raté, par chance).
J'ai fait aussi, mais j'ai eu quelques emmerdes avec ça alors j'ai préféré passer au modèle "multiple browsers": dillo pour le sans JS, FF pour le chteumeuleu5, vivaldi(chromium quoi) pour le pepper. J'ai depuis posé une question sur le forums vivaldi, du coup FF est sur le point de disparaître de l'équation. Je ferais sûrement un autre journal sur vivaldi quand ils passeront leur v1 release candidate ou stable. Avec une MàJ de mon expérience sur Otter au passage, au cas ou ils auraient fini par avoir un truc exploitable par défaut.
Tout le monde l'est. Jusqu'a ce que l'on trouve LE détail qui fait qu'en fait, ben non :)
Je veux dire, si je devais résumer la sécurité utilisable en quelques mots ce serait: "La sécurité, c'est se méfier de tout le monde, sauf des gens pour lesquels ça nous gêne.". Donc, si ça te gêne de faire confiance à google, ok, tu es en sécurité si tu ne te méfies pas d'eux.
Y'a un moment, on est obligé de faire confiance à quelqu'un… peu importe qui. Ou alors tu te méfies de ton marchand de fruits et légumes, ainsi que du type qui te vends les anti-poison pour ce dernier etc etc et on n'en finit jamais.
[^] # Re: Et pour les virus?
Posté par ariasuni . Évalué à 2.
Firefox, mais à bien y réfléchir c’est sans doute parce que j’ai mis
media.fragmented-mp4.exposed
à vrai dansabout:config
(ce qui sera bientôt le cas par défaut normalement). Mais Dailymotion est TELLEMENT MIEUX en HTML5, genre adieu la plupart des problèmes.Effectivement, Rutube ne marche pas. Pour les sites qui marchent pas (Nico Nico Douga), j’utilise youtube-dl: pas optimal, mais fonctionne très bien.
Enfin Flash est encore présent mais ça ne sera bientôt plus un problème à mon avis, en particulier à cause de l’augmentation de l’usage des système d’exploitation mobiles qui ne l’ont pas.
(Bon après y a toujours les sites de rattrapage télévisuel qui fonctionnent qu’avec Silverlight et Internet Explorer mais là c’est un autre niveau)
Ah mince, moi ça marchait bien (je l’ai utilisé pendant plusieurs mois, même sur Youtube au début).
D’où l’intérêt des signatures pour les dépôts, ça augmente la confiance sur la durée. Mais évidemment ce problème est valable pour tout, même ton matériel.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 1.
Je vois. Pour ma part, j'ai choisi de faire confiance à un logiciel fermé pour le web. Celui-ci à une configuration par défaut qui est déjà décente (pas nickel, loin d'être parfaite même, mais au moins décente) contrairement au… "fleuron du libre" qu'est firefox. Ironiquement, quand je suis tombé amoureux de firefox, je ne connaissais rien à l'informatique, et je l'ai aimé pour ses onglets multiples, que maintenant je décrie, clamant qu'ils devraient être l'œuvre du gestionnaire de fenêtres, alors que IE n'avait PAS ce bloat précis :)
C'est drôle, la vie.
Ça, c'est encore un truc qui fait que je préfère ne pas utiliser firefox. Un logiciel doit faire une chose et la faire bien, selon UNIX. Firefox à choisit d'être diversifié, comme de nombreux outils de qualité, soit. Dans ce cas, qu'ils assument, et arrêtent de rejeter leur UX merdique sur les extensions. Par défaut, FF est une galère à utiliser pour celui qui veut un browser potable. Par défaut veut dire, sans plug-in. Et potable veut dire, qui garantisse au moins l'un de ces aspects: utilisable, favorisant la vie privée, léger en ressources. Il se peut qu'en terme de potabilité, ce soit l'un des pires…
Bon, j'utilise FF. C'est mon fallback, parce que le navigateur que j'utilise est en alpha, donc, rarement, il arrive qu'il ne soit pas idéal. Rarement. Mais je me trompe de troll pardon :)
Nombreux sont les devs qui ont souhaité la même de COBOL. J'exagère, bien sûr, mais le // est pertinent, non? Genre, tu crois vraiment que la majorité des gens en ont quoique ce soit à foutre?
Honnêtement, il y a des applications pro sous flash qui seront dures à recoder en entier (oui, en entier, d'ailleurs j'ai cru comprendre que c'était déjà une galère de les maintenir alors que tous les devs d'origine étaient partis hinhinhin).
Pendant ce temps là, elles ne sont plus maintenues sous linux (ce qui en fait au final la meilleure solution pour les faire tourner, mais personne ne le comprend, crétins de chefs de projets! mais je suis pas un décideur, et je suis parti depuis 1 an alors je ris). Mais dans la pratique, la peur de l'absence de MàJ, qui ne touche que les non informaticiens, fait que les gens vont rester sous windows pour faire tourner ces systèmes. Après tout, il me semble que flash est encore maintenu sous win.
Et en faisant abstraction de mon pavé précédent, ce n'est que ton avis, de toute façon. Si seulement tu pouvais être un prophète, et si seulement ça pouvait arriver cette année cet abandon, je serait bien content.
Juste une expérience personnelle. Le genre qui diffère souvent quand on utilise des système bizarroides, mais pour le net, je me suis limité au standard: firefox pendant…. pfff trop longtemps à mon goût.
Pour ça que j'ai mis l'accent sur la prolifération des relations de confiance, et non pas sur la notion de confiance elle-même. Tout en mettant également un accent sur le fait que dans le cas ou un seul tiers (c'est le cas de nos jours sous Debian stable) fournis les logiciels. Après tout, si ce tiens est compromis au mauvais moment, tu te fais infecter, et si tu n'as qu'une source de confiance, tu es "mort".
À contrario, avoir plusieurs sources de confiances pour un même paquet permettrait d'avoir une meilleure sécurité: imagine diverses sources de confiance avec chacune leur signature. Toi, tu fais ta demande de MàJ comme d'hab. Une MàJ se pointe, tu dl le paquet de toutes les sources possibles, et la, merde, y'en a une qui diffère!?! Au moins il y a un signe, alors que, à l'heure actuelle sous Debian, tu es obligé de faire confiance à une seule source je crois. Et en tout cas c'est comme ça par défaut.
La grande faille de la sécurité, c'est toujours la confiance.
[^] # Re: Et pour les virus?
Posté par Antoine . Évalué à 4.
Plein de logiciels trop spécialisés pour être empaquetés correctement dans ta distribution. La plupart des logiciels métier par exemple, les outils spécialisés pour le calcul scientifique, nombre de bibliothèques utiles au développement, etc.
Il y a aussi le problème des logiciels qui évoluent trop vite par rapport au rythme de maintenance de la distribution, ce qui est courant quand on parle d'un logiciel récent.
[^] # Re: Et pour les virus?
Posté par Thomas Debesse (site web personnel) . Évalué à 6. Dernière modification le 31 mars 2016 à 18:03.
Même si les jeux Steam ne sont pas dans le dépôt de ta distro, pour l’utilisateur, c’est un dépôt avec un certain effort de qualité et de sécurité. Si le cousin Georges n’installe que des programmes via Synaptic ou Steam, il court pas de grand risque…
Perso je compte Steam comme un dépôt… C’est un catalogue contrôlé de logiciels.
Donc oui, quand ton cousin Georges a Ubuntu et Steam il est assez en sécurité, mais quand il va devoir installer un autre programme, il commence à rentrer sur le champ de bataille.
Soit c’est un geek qui veut des logiciels en préversion et en général il va utiliser un PPA, ça commence à être un sérieux problème de sécurité car lorsqu’il installe la clé d’un PPA le cousin Georges autorise ce PPA a remplacer tout son système (donc il suffit d’un PPA compromis et hop). Alors le cousin Georges va faire confiance à de plus en plus d’entités, l’équipe qui compile ses pilotes en avance, l’équipe qui compile son Gnome en avance, etc.
Mais on a vu avec Mint que tout le monde n’a pas les épaules d’Ubuntu ou Debian. Et autre exemple : si PlayDeb n’a jamais été compromis à ma connaissance, ils ont clairement pas les épaules de Steam. Un jour, un PPA très populaire va se faire compromettre sérieux et on aura tous l’air fins.
Et puis le cousin Georges il va vouloir installer des trucs encore plus risqués, des .deb téléchargés comme ça sur le net, comme Skype (et en fait il aura déjà fait ça pour Steam la première fois) ou Chrome. Là c’est déjà l’embuscade.
Et puis le cousin Georges il va vouloir essayer la dernière beta de cinelerra parce qu’il se pique de montage vidéo pour sa chaîne youtube, ou une build de netradiant parce qu’il veut faire une funmap de märde pour Xonotic. Ça fait longtemps qu’il n’a plus froid aux yeux le cousin.
Et puis un jour le cousin Georges il va chercher csgo-linux-nosteam.txz sur tipiakbay et là c’est carrément le feu nourri.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Et pour les virus?
Posté par ariasuni . Évalué à 2.
En même temps, si la personne commence à installer des PPA, elle sait qu’elle lui donne sa confiance. Au pire faut informer ces utilisateurs/trices avancé-e-s des risques des PPA, leur apprendre les bonnes pratiques (enlever les PPA dont on se sert plus par exemple), etc. Mais ce sont également des dépôts contenant des paquets signés, non? Ça doit pas mal limiter la casse si les clés fuitent pas.
Euh Skype, Steam et Chrome (bon, Chromium) c’est pas déjà dans les dépôts?
Mon argument c’est surtout que télécharger moins de trucs n’importe où sur le net, c’est plus sûr. Au moins pour ces logiciels là le risque est fortement réduit. Évidemment le risque reste le même quand on choppe des jeux en dehors d’un dépôt ou de Steam, ou quand on choppe des cracks pourris (je crois que j’ai infecté ma machine virtuelle Windows à chaque fois que j’ai voulu activer l’OS, en fait).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 2.
Sous Debian stable, skype, steam et chrome ne le sont pas, mais chromium oui. Et pas de parenthèses, ce sont des logiciels TRÈS différents (assez, tu noteras, pour que 1) je fasse cette parenthèse et 2) j'ai fait mon emacsien pour pondre un "È", j'ai même du utiliser mon nez boudiou!).
Au final, le problème n'est pas de devoir faire confiance à peu d'organismes, mais à de nombreux organismes qui donnent chacun un truc différent (debian pour 95%, clang, vivaldi, à une époque codeblocks, openmw c'est debian sid mais j'ai fini par juste importer le git…), et de savoir mesurer les risques, et réparer si besoin est.
Moi, utilisateur de linuxfr, et accessoirement développeur plutôt bricoleur, je saurai réparer ma (et juste, MA) debian si une merde se pointe, et identifier les données corrompues. Encore faut-il que je m'aperçoive que j'ai une merde…
Si moi je m'en aperçois pas, la moyenne le verra encore moins (quoique…).
Ils sont éduqués sous windows, un système dont l'écosystème est une pure jungle… ils se croient accoutumés à la jungle, et se chopent des merdes de cette façon, trop confiants. S'ils passent sous linux, tu penses qu'ils changeront de comportement? Non! Et ils l'ont prouvé: il existe des antimalwares sous android, qui est, basiquement, linux.
Typiquement, demandes autour de toi qui connaît "téléchargez.com" ou son successeur, désolé, j'ai vraiment divorcé de windows, je suis sûr qu'il y a un remplaçant… clubic, peut-être?
En même temps, on est tous d'accord, le problème c'est "télécharger moins de trucs n’importe où sur le net, c’est plus sûr" ou, reformulé: limiter les sources de confiance (comme pour le SSL ou github en fait) pour réduire le risque d'infection.
Mois l'on a de sources, moins l'on risque l'infection. Parallèlement, moins on a de sources, plus on est vulnérables à une source compromise (signatures ou pas je pense). Du coup c'est ironique, si on pouvait avoir plusieurs sources de confiance pour un même paquet, OU ASSEZ PEU DE PAQUETS INSTALLÉS, il ne serait pas aussi difficile de maintenir une relation de confiance avec les fournisseurs. Tout ça me semble actuellement l'opposé de ce que je vois chez Debian. D'ailleurs, j'ai cessé de m'impliquer, je cherche à changer. Pour un truc plus maintenable.
[^] # Re: Et pour les virus?
Posté par ariasuni . Évalué à 2.
Ben je pensais à Ubuntu, Fedora ou Mageia, les distributions les plus utilisées pour le bureau par les néophytes.
En quoi Chrome et Chromium ne sont pas si différents que ça? Sous Linux, en terme d’utilisation, les seules différences majeures sont l’intégration de Flash Player par défaut (téléchargeable indépendamment) et des icônes plus colorées chez Chrome.
Notons au passage que la page Wikipédia est pas du tout à jour sur les sujet, puis que les mp3 et AAC, le lecteur PDF et la prévisualisation avant impression fonctionnent très bien dans mon Chromium.
C’est si compliqué de faire un È en azerty (ou autre dérivé de qwerty que tu utilises, je suppose)?
Ça dépend, les guides et documentation et utilisateur/trices de Linux leurs diront généralement de passer au maximum par les dépôts. Du coup y a des chances que les néophytes changent de comportement grâce à la culture linuxienne. Je dis pas que c’est miraculeux mais si on leur explique que les dépôts c’est plus sûr, les gens vont surement avoir tendance à plus utiliser les dépôts.
Telecharger.com redirige vers 01net.com. Site bloqué par la liste «uBlock filters – Badware risks» accessoirement.
Ça dépend, si les clés sont stockés à un endroit bien protégé, l’accès simple à l’espace de stockage du dépôt n’est pas suffisant, et inversement.
J’y ai un peu réfléchi, et je me disais que ça serait peut-être plus simple d’avoir la possibilité d’ajouter des dépôts qui marcheraient pour plusieurs distributions, genre un dépôt Firefox (avec Firefox stable, developper et nightly), un dépôt VLC, un dépôt LibreOffice, etc. Peut-être qu’avec l’arrivée d’AppImage, on pourrait voir ça émerger?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 2.
Réflexe, je précise toujours ma distro. Question: est-ce vraiment si différent d'une Ubuntu? D'ailleurs, je n'ai aucune idée de la différence, outre l'IDE par défaut.
Me semblait qu'il y avait des histoire d'envoi de données vers des serveurs google via des plug-ins, qui, sans être particulièrement suspicieux, ont fait émettre des doutes. Mais, j'avoue, c'est plus du FUD de ma part basé sur des rumeurs. 0 source.
Toujours un bon argument pour troller quand on a rien à dire non? :p en gros: de l'humour, et je pensais que c'était évident….
Ça se tiens. Le problème est de leur enseigner à lutter contre leurs instincts: ne pas cliquer sur le 1er lien. Et si on ne peux pas, leur apprendre à utiliser un moteur qui indique le site officiel en 1er, plutôt que de la pub.
Parce que malheureusement, nous ne serons jamais assez pour être derrière tout le monde au moment ou ils feront une erreur. Et l'éducation implique 2 efforts: de l'enseignant, et surtout de l'apprenant.
Comme je l'ai dis, je n'ai pas utilisé ces merdes depuis des années…. putain me fais vieux du coup….
Mais il faut toujours faire confiance à tiers, et c'est bien la le "problème".
Voila, la est le vrai point de discussion au final :) j'espérais pouvoir compter dessus, le reste était plus du meuble et du troll, parce que les débats sont des jeux pour moi. Alors je joue. Toujours.
Oui, je pense qu'avoir des dépôts unifiés à un logiciel sont une option, d'ailleurs, c'est ce que j'utilise pour avoir clang.
Malheureusement, ça implique qu'un même dépôt serait vulnérable pour toutes les distrib. Pour un logiciel comme firefox, imagines la crise… et l'impact!
La seule solutions que je peux voir, si on veut une confiance à 99%, c'est d'avoir 100 dépôts différents et indépendants pour chaque paquet, avec des binaires reproductibles (il y a des études à ce sujet d'ailleurs, sur les binaires reproductibles) et de télécharger un nombre aléatoire (fonction de la sécurité que l'on souhaite obtenir) et comparer les signatures. Si une seule diffère, demander à l'utilisateur quelle source utiliser. Tu l'auras bien entendu remarqué, ça implique de multiplier par n (le nombre aléatoire) la bande passante nécessaire, ce dont on peut difficilement se permettre sans p2p généralisé. Et pour le p2p, je n'ai aucune idée du taux de garantie fournis.
Un autre niveau de protection serait de pouvoir installer des logiciels par utilisateur, sans risque de se choper un hook. Mais, c'est inapplicable aux distrib basées sur debian pour commencer, et pire, ça ne protège pas les données des utilisateurs.
La sécurité est vraiment un sujet très complexe, et une sécurité de 100% implique que l'ont ne peut pas utiliser le système, ce qui n'est pas le but. La seule options est d'éduquer les gens, mais tout le monde considère l'informatique comme une science occulte (pour notre bien? pas si sûr…)
[^] # Re: Et pour les virus?
Posté par ariasuni . Évalué à 3.
IDE? Tu veux dire Desktop Environment plutôt?
Si tu ne connais la différence entre Debian et Ubuntu, tu ne peux pas vraiment juger de la facilité d’utilisation d’une distribution GNU/Linux grand public.
Ah mais Chrome est un gros mouchard, même Chromium a des comportements louches. Juste qu’un terme d’utilisation c’est du pareil au même.
Désolée, je pensais que c’était sérieux, bien qu’exagéré.
Oui c’est sûr, quelque soit l’OS, l’outil informatique n’est pas magique malgré ce que certains commerciaux essaient de nous faire croire.
Je dis juste qu’une fois qu’on a fait confiance une première fois pour télécharger les clés, on peut avoir une meilleure confiance pour cet acteur. Ça ne supprime pas le problème de la confiance mais .
Ben y a une version de Firefox pour Windows qui représente bien plus d’utilisateurs/trices. Les distributions GNU/Linux, c’est peut-être non-négligeable pour Mozilla mais c’est quand même largement moins!
Ça serait quand même assez compliqué. Je vois pas l’intérêt par rapport à un système de signature de paquets avec clé hors-ligne ou sur un serveur séparé protégé par un mot de passe ou protégée par un mot de passe très fort. Bon évidemment dans ce cas faut faire confiance à une seule personne, mais on a peut-être pas envie de dépenser des centaines d’euros sur des centaines de plateformes pour faire des centaines de plateformes qui vont consommer beaucoup d’électricité très souvent.
Créé des binaires reproductible, ça me semble très intéressant aussi: l’équipe de surveillance des CVE de Arch s’y est intéressée, et je crois qu’y a du boulot en cours sur le sujet pour Debian.
Pour le coup, je vois pas vraiment l’intérêt d’installer des logiciels par utilisateur (en tout cas en matière de sécurité).
Faut dire que ça arrange bien les marchands de boites à coucou de faire croire que leur truc marche tout seul. L’informatique est un domaine jeune, et les non-experts n’ont pas encore assez de recul. Faut continuer à asséner que l’éducation à l’informatique (genre, pas le B2I ou autre «apprendre à utiliser WordArt») c’est très important.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 2.
C'est sûr, mais Mozilla reste un gros poisson, dont ont peu espérer une certaines compétence sur la sécurité réseau (c'est leur cœur de métier). La plupart des éditeurs logiciels ne sont pas nécessairement d'aussi gros poissons, n'ont pas nécessairement autant de moyens.
Si le nombre de sources logicielles augmente, on augmente le nombre de points fragiles: plus on a de sources, plus on est vulnérables. D'un autre côté, plus on a de sources, moins on est vulnérables à une attaque globale…
D'où une solution (exploitable uniquement par les logiciels open source) serait d'avoir des organismes indépendants qui fournissent le même paquet pour les mêmes distributions. De cette façon, avec la compilation reproductible, on pourrait rendre nettement plus complexe le vérolage d'un paquet, justement parce qu'il n'y a plus de confiance à une seule personne.
Mais, reste à définir la limite entre la sécurité et la paranoïa… sachant que la paranoïa à un coût extrêmement élevé, je te rejoins sur ce point (comme je l'avais laissé sous-entendre d'ailleurs).
Ça empêche une prise en main complète du système dans le cas d'un logiciel vérolé. Sachant que sous Debian, c'est presque "soit t'es root, soit tu l'es pas" (par exemple, pour éteindre le PC il faut être root… pas moyen de donner ce droit à un utilisateur, selon mes pauvres recherches, ce qui du coup force à utiliser sudo, qui ressemble plus à un workaround qu'a une véritable solution selon moi), de ce que je sais. J'ai cru comprendre que sous les *BSD le partitionnement des droits par groupes est plus fin, mais je n'ai pas encore expérimenté.
Si un seul utilisateur installe un logiciel, le logiciel ne pourra pourrir la vie que de cet utilisateur la. Pas celle des autres.
C'est d'ailleurs la raison pour laquelle wine, par défaut, installe dans le $HOME des utilisateurs et non dans le système complet, il me semble.
Désolé mais, de nos jours, ce n'est pas l'éducation à l'informatique qui est la pire lacune de l'éducation, malheureusement. Bien que je suis d'accord: il faut éduquer ceux qui s'en moquent. Dur dur, mes profs de langues ont essayé et je ne suis pas persuadé de leur succès :D (quoique, mon niveau en français et anglais me semble décent, en fait).
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 4.
Il se passerait quoi, si tu avais installé linux mint? Je veux dire, celle dont l'iso semble avoir été modifiée il n'y à pas si longtemps?
Accessoirement, tu en penses quoi des PPAs et autres mécanismes semblables, destinés à rendre l'installation d'un logiciel tiers plus facile? Il y à moins de, sinon aucun, contrôle dessus, pas vrai?
Ça, on est d'accord. Du moins, tant que l'on parle d'installation manuelle.
Il ne faut pas oublier un problème majeur: pour un langage interprété (python, sh, … mais surtout javaScript!) ce n'est pas difficile de se faire exécuter, par exemple via le navigateur. D'ailleurs, le navigateur web est probablement la 2ème plus importante source de malware… voire la 1ère, à bien y réfléchir: tout le monde l'utilise, pas juste les joueurs.
Pour le marquage en exécutable, ne pas oublier que la plupart des malwares modernes sous windows demandent à l'utilisateur le droit de s'exécuter… Ils feront pareils sous linux (même si oui, du point de vue sécurité, on est par défaut mieux lotis sous Debian que sous Windows, et j'ose espérer que toutes les distributions mères sont du même niveau).
Je ne dis pas que c'est trivial, hein, juste que c'est largement faisable, et mon but c'est de tordre le cou à l'idée super débile que parce qu'on utilise un logiciel alternatif, on est insensibles aux malwares.
Quand j'étais sous windows, j'y étais résistant aussi en fait, parce que je n'utilisais aucun logiciel mainstream, quasiment que des alternatives libres. N'empêche, rien ne prouve que personne n'attaquais ces outils (d'ailleurs, certains de ces outils me manquent, notamment les débogueurs, il n'y a que dalle de vraiment efficace sous GNU/Linux dès qu'on ne veut pas se farcir un IDE… snif… et en plus gdb aime pas clang… grrr!).
Le problème viens toujours de l'administration. Si l'administrateur marque le système de fichier contenant /home comme ne pouvant contenir d'exécutables, le problème est réglé. Avec les problèmes que ça inclue: l'utilisateur ne peut plus installer d'applications inconnues de l'admin.
La sécurité ça à toujours un impact sur l'utilisabilité. Windows est trop léger (mais s'est amélioré) par défaut, mais nos distrib sont, peut-être, un peu trop casse-pied (ça, ça reste un vrai débat) pour un usage lambda?
Pourquoi?
Je suis quasiment sûr que 90% des distributions Linux de bureau on bash, systemd, dkms, sudo, python 2 et 3, perl, ssh et Xorg d'installés (j'ai un doute pour netcat…). Je me trompe? Et si y'a pas Xorg, alors c'est wayland, qui a une couche de compat' de mémoire. Avec tout ça, il y a largement de quoi attaquer à l'aveugle.
Pire, la diversité des distributions Linux n'est pas si importante: combien de distrib sont juste basée sur une autre, avec un simple fichier qui change les paquets installés par défaut et un thème graphique différent? Avec aucun paquet dont la compilation ou même la configuration serait différent de l'original?
Question subsidiaire, du coup, quel est le degré de similarité entre une Debian sid et, mettons, emmabuntu (j'ai pris le nom au pif, pour la forme)? Je suis quasi sûr qu'il dépasse les 50% à l'aise, particulièrement au sujet des paquets qui forment le cœur du système.
Après tout, ce qui change le plus, c'est le bureau… la couche graphique, celle qui est tellement difficile à expliquer aux gens que l'on préfère sur les forum utiliser des lignes de commande pour dépanner les autres.
Je pense que c'est plus compliqué parce que les utilisateurs sont mieux éduqués en moyenne. Pour l'instant.
Reste que j'ai, comme déjà dit, la conviction qu'Android possède un bon réservoir à malwares. Hors, l'affirmation que je veux démonter, c'est que seul windows est victime de malwares… pardon, de virus, parce que pour les malwares c'est encore plus simple à prouver: il suffit de parler des rootkits qui servent à attaquer les serveurs.
[^] # Re: Et pour les virus?
Posté par ariasuni . Évalué à 3.
LLDB me semblait prometteur à l’époque où j’ai appris son existence, je sais pas du tout où ça est mais c’est peut-être un outils à tester/dont tu devrais suivre l’évolution?
Globalement d’accord avec le reste, je pense pas que Linux soit spécialement plus sécurisé d’ailleurs Windows semble s’être bien rattrapé côté sécurité. À la limite on a peut-être moins de failles dans certains logiciels, mais pas sûr que ça contrebalance les projets maintenus par une personne et demi (OpenSSL…).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 2.
Il me semble aussi prometteur.
Maintenant, c'est toujours pareil, apprendre à manier la ligne de commande, c'est un investissement, et taper régulièrement les mêmes commandes ou séquences de commandes (afficher le code source, typiquement?) est un inconvénient de la ligne de commande.
Pour certaines choses les applications interactives sont bien plus efficaces, et le débogage en fait partie. Pouvoir apprendre la ligne de commande des débogueurs, pour les usages avancé me paraît utile, mais devoir l'apprendre pour les usages basiques me semble contre-productif.
Mon fallback actuel, c'est cgdb, mais ça reste assez primitif et, encore une fois, je suis obligé de compiler avec gcc pour que ça passe (sous Debian), alors que j'utilise clang pour avoir des messages de compilation lisibles.
En théorie, il a un mode interactif (de même que gdb d'ailleurs) mais de ce que j'ai vu la dernière fois que j'ai testé (6-7 mois) ça ne me semble pas vraiment utilisable. Peut-être un manque d'efforts de ma part… mais quand on connaît la qualité des débogueurs windows hors-IDE, la différence est claire (j'en connais au moins 4, dont 2 freewares, et même le plus primitif d'entre eux, windasm32 je crois, est 10 fois plus simple à utiliser que ceux que j'ai essayé sous Linux). C'est sûrement lié au fait qu'il y ait plus de crackeurs et virus sous windows, pour le coup :)
[^] # Re: Et pour les virus?
Posté par claudex . Évalué à 10.
Ils implémentent l'API Windows, donc les mêmes virus devraient pouvoir fonctionner. Si tu trouve un virus qui ne fonctionne pas, je pense que tu peux soumettre un rapport de bug.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et pour les virus?
Posté par KiKouN . Évalué à 0.
À qui ? À Microsoft ou à ReactOS ?
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 3.
Techniquement, au deux.
Si le virus utilise l'API windows et que ça marche pas comme la doc le décrit, c'est un bug de l'API MS, et si le comportement sur ROS n'est pas le même que sur WOS (windows OS) ou différent de la doc MSDN, alors il y a peut-être un bug sur les deux. Un virus est un soft comme un autre, après tout. Tout comme un tournevis peut me permettre de tuer ce p***** de voisin trop bruyant :p
[^] # Re: Et pour les virus?
Posté par KiKouN . Évalué à 1.
Un virus n'est pas un soft comme les autres. Il exploite les faiblesses d'un système pour accomplir sa tâche.
Même si ma question est ironique, du moins, à la base, le bug est bien avant tout du côté de microsoft. C'est après à reactos a s'adapter.
Pour la comparaison avec un meutre, le bug ne vient pas du tournevis, mais de l'homme. Le tournevis n'exploite pas de lui-même sa capacité à assasiner.
[^] # Re: Et pour les virus?
Posté par freem . Évalué à 2.
Il n'empêche, il n'y a pas que les malwares qui exploitent intentionnellement ou non des bugs de l'API, des logiciels normaux aussi (raison pour laquelle certaines applications w9x ne passent plus de nos jours sur un noyau NT malgré la couche de compatibilité: certains bugs ont été corrigés, et les applications en question en avaient besoin…).
Donc, si ReactOS se veut 100% compatible avec windows, il doit fatalement fournir une compatibilité avec les virus, éventuellement en option.
On peut aussi imaginer utiliser ReactOS comme environnement pour étudier le fonctionnement des virus afin de trouver un antidote, et dans ce cas il est nécessaire que même eux puissent fonctionner.
D'ou le fait que j'ai dit, qu'il faudrait envoyer un rapport de bugs aux deux: à MS et à reactOS. À MS pour qu'ils bouchent la faille, à ReactOS pour qu'il la créent ou la simulent le temps que MS règle le problème.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.