À la différence du projet Wine, avec lequel il collabore, ReactOS n'est pas une sur-couche à un autre système d'exploitation, mais un système indépendant. Son architecture étant pensée pour être compatible avec Windows, la compatibilité devrait être meilleure par rapport à Wine + GNU/Linux en particulier au niveau des pilotes. Les pilotes / DLL / exécutables Windows devraient être utilisables directement sur ReactOS.
La version 0.3.9 apporte principalement, outre les corrections de bugs habituels, une réduction de la taille mémoire minimale requise (désormais 32 Mo), la mise en œuvre d'une interface de "mapping hyperspace" (Hyperspace Mapping Interface) plus rapide, un meilleur moteur de rendu (détails en seconde partie de dépêche).
ReactOS est disponible sur le site officiel sous plusieurs formes :
- CD d'installation : attention le logiciel est encore à un stade alpha (ce sera le cas jusqu'aux versions 0.5.x), ce qui signifie qu'il est déconseillé de s'en servir comme système principal
- Live CD, vous permettant de tester sur votre matériel sans installation sur disque dur
- Images pour différentes machines virtuelles (QEmu, VMWare) qui devraient également fonctionner sur d'autres (Bochs, Virtual PC)
- version de débogage si vous voulez mettre les mains dans le cambouis et vous essayer au développement d'un OS.
- une pochette CD/DVD est même disponible en PNG/PDF (pour la version 0.3.1 ceci dit, mais un petit coup de GIMP/Krita devrait arranger ça)
- Réduction de la mémoire minimale requise à 32 Mo. En théorie, ReactOS peut maintenant être installé avec 24 Mo et s'exécuter avec seulement 20 Mo
- Un nouvelle, plus rapide, interface de mapping hyperspace (Hyperspace Mapping Interface) est implémentée dans le noyau, apportant une amélioration de la vitesse de plus de 300 %
- Des améliorations dans les contrôles de sécurité du gestionnaire d'objets du noyau augmentent les performances de 500%. C'est sensible pendant les opérations sur les gros fichiers ou la base de registre.
- Plusieurs problème sur NDIS (spécification de l'interface du pilote réseau) et AFD ont été résolus, ce qui augmente la compatibilité avec les pilotes NIC tiers et améliore la robustesse de la pile réseau
- Début du support pour le son via le nouveau service de streaming du noyau. Il est désormais possible d'utiliser les pilotes ac97 via la nouvelle bibliothèque "Port Class library" pour jouer de la musique en utilisant winamp
- Il y a eu un gros effort pour rendre la ligne de commande plus compatible avec celle de Microsoft. Elle peut maintenant exécuter des scripts vraiment complexes, dont l'environnement de compilation de ReactOS.
- De nombreuses corrections de bogues dans les portions noyau du GDI (interface des dispositifs d’affichage, un des composants fondamentaux de Windows pour la représentation des objets graphiques), apportant un moteur de rendu bien meilleur.
- Une synchronisation avec les DLL de Wine
ReactOS a énormément progressé ces dernières années, malgré des remous au moment de l'audit interne (cf. page Wikipedia pour plus de détails). Les auteurs cherchent à apporter le fonctionnement du système de Microsoft, mais avec la philosophie du Libre. Pour ceux qui préfèrent le mode de fonctionnement de ce système (probablement pas grand monde sur ce site ;) ), ou qui veulent avoir un système en double amorçage pour utiliser des applications (jeux ?) ou des pilotes qui ne fonctionnent pas (encore...) sur GNU/Linux, ReactOS est séduisant, d'autant plus qu'il supporte nativement Grub et Ext2, ce qui rend sa cohabitation avec notre manchot plus facile.
Aller plus loin
- Site officiel (76 clics)
- Site officiel anglophone (10 clics)
- Page Wikipedia (11 clics)
- Wine (6 clics)
- Annonce officielle et journal des modifications (7 clics)
# But?
Posté par bob le homard . Évalué à 9.
Parce que si je comprends bien l'idée, je reste un peu sceptique sur la faisabilité de votre projet. J'ai l'impression que votre tâche est immense!
Aujourd'hui, win2000 commence sérieusement à se faire vieux. De nombreux programmes ne s'installent même plus dessus et demande au minimum Windows XP.
A première vue ça a l'air attrayant de se dire qu'on pourrait faire tourner des logiciels qui ne fonctionne que sous windows (je pense à certaines applis metiers dont on a du mal à se séparer dans certaines petites structures)... le tout sans payer de licence windows.
Mais je trouve que vous avez 2 gros concurrents de poids : wine et les machines virtuelles.
Donc est ce que le système se limite à du win2000 où va-t-il au delà (windows xp)?
[^] # Re: But?
Posté par Dr BG . Évalué à 10.
XP étant NT 5.1, j'imagine qu'il est visé.
[^] # Re: But?
Posté par bob le homard . Évalué à 2.
Je ne sais pas : ca ne me parait pas si clair, par exemple Chrome ne fonctionne pas sur 2000.... mais peut-être qu'il fonctionnera sur ReactOS remarque ;o)
[^] # Re: But?
Posté par bilboa . Évalué à 7.
"ReactOS® is a free, modern operating system based on the design of Windows® XP/2003"
la plupart des articles du site referent a Windows XP
[^] # Re: But?
Posté par Gniarf . Évalué à 9.
il fonctionne très bien, ce sont ces branleurs de chez Google qui ont décidé de ne supporter que XP SP2 et au delà sans raison technique valable derrière. c'est juste l'installateur qui fait quelques vérifications, "mentir" sur les versions de quelques DLLs suffit pour l'installer et l'utiliser sans problème derrière
idem chez Apple pour Safari/Quicktime/iTunes (sauf quelques considérations liées aux DRM, que permet justement XP SP2 et pas les versions précédentes)
en fait les vrais apports d'un XP SP2 par rapport à un 2000 SP3 ou SP4 sont précises et foutrement rares. et les clowns qui prétendent que leur soft nécessite vraiment "la dernière version du service pack" juste pour s'éviter quelques tests et du support méritent de se faire cracher à la gueule.
[^] # Re: But?
Posté par Maclag . Évalué à 4.
Par contre, là où je vois un intérêt, c'est là: 24Mo de RAM pour le faire tourner!
Je ne sais pas pour vous, mais à l'époque de 2000, il fallait un chouïa plus!
ReactOS, la future vraie alternative à Linux pour les notebook?
Une version ARM dans les bacs?
[^] # Re: But?
Posté par inico (site web personnel) . Évalué à 2.
http://www.reactos.org/wiki/index.php/ReactOS_Portable_Syste(...)
Le port ARM était en route mais il a l'air d'être stoppé depuis Mars.
Sur un autre sujet, Windows XP peut fonctionner sur 24Mo de RAM après quelque modification.
Il y a plein de monde à l'exterieur de Microsoft qui est capable de t'en faire une image (google tinyXP & nanoXP )
[^] # Re: But?
Posté par JoeBlack . Évalué à 10.
Je ne vois pas en quoi les machines virtuelles sont un concurrent de poids pour ReactOS sur le terrain de la licence et du prix : une machine virtuelle sous windows est censée posséder une licence propre...
[^] # Re: But?
Posté par Sébastien FRADE . Évalué à 3.
Bien qu'ayant Wine d'installé sur mon ordinateur personnel, je trouve l'idée alléchante d'avoir un système libre compatible Windows. Le seul soucis à mes yeux: j'espère que ReactOS, bien que voulant être compatible Windows saura éviter de commettre les erreurs de sécurités de ce dernier en établissant des règles strictes quant aux droits d'utilisateurs (comme on en trouve parmis les unices).
Mais en effet, les machines virtuelles n'apportent absolument pas la même offre que Wine ou ReactOS. Franchement, faut arrêter de tout mettre dans le même sac.
[^] # Re: But?
Posté par pasBill pasGates . Évalué à -4.
T'as un exemple concret et reel d'erreur de ce type ? Ca m'interesse.
[^] # Re: But?
Posté par djibb (site web personnel) . Évalué à 10.
-> PAN.
[^] # Re: But?
Posté par pasBill pasGates . Évalué à -1.
B) Ca fait des annees que cela ne marche plus que ce soit avec Outlook ou IE, faudrait penser a rafraichire tes connaissances
[^] # Re: But?
Posté par Kerro . Évalué à 10.
Sous Vista ce n'est pas mieux car n'importe qui clique sur "oui oui j'autorise le truc demandé"... "heu c'est quoi que j'ai validé là ?".
Juste deux exemples de base, mais alors vraiment de base :-)
[^] # Re: But?
Posté par pasBill pasGates . Évalué à 5.
C'est pas difficile du tout, enormement de societes tournent de cette maniere.
A la maison si tu veux changer tes parametres reseau ou autres tout le temps, c'est que le probleme est ailleurs.
Faudra m'expliquer ce qui, dans l'OS, demande un acces admin sous Windows et pas sous Linux.
Sous Vista ce n'est pas mieux car n'importe qui clique sur "oui oui j'autorise le truc demandé"... "heu c'est quoi que j'ai validé là ?".
Avec un compte utilisateur, il leur faut entrer le mot de passe, si ils sont pas foutus de faire attention, ils auront exactement le meme probleme avec Linux.
[^] # Re: But?
Posté par goom . Évalué à 6.
[^] # Re: But?
Posté par fasthm . Évalué à 2.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: But?
Posté par Kerro . Évalué à 7.
C'est pas difficile du tout, enormement de societes tournent de cette maniere.Uniquement les entreprises qui ont un vrai bon service informatique. Ce qui tend à prouver que c'est loin d'être facile. Alors qu'avec Unix c'est par défaut.
Beaucoup de logiciels des gros éditeurs nécessitent d'être administrateur de son poste (CEGID par exemple, je connais bien). Ce n'est pas à cause des _possibilités_ de l'OS, c'est à cause du quotidien de l'OS, car par défaut, c'est grand ouvert, et les programmeurs qui ne connaissent que MS sont _souvent_ des billes.
[^] # Re: But?
Posté par Larry Cow . Évalué à 4.
[^] # Re: But?
Posté par Kerro . Évalué à 3.
Si on prends les PME "normales" avec 5 à 15 postes sous Windows et un serveur de fichiers, c'est kif-kif avec du Linux. Sauf que ça coûte moins cher en licences et matériels, sauf qu'il y a moins de logiciels pour certaines choses. Mais l'un dans l'autre c'est kif-kif.
La plupart des PME sans service informatique font appel à des prestataires qui sont en dessous de tout. Ce ne serait pas pire avec du Linux :-)
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
* Pas d'équivalent des bits suid ou du sudo. Bilan, c'est merdique de déléguer une partie de l'administration du poste.
* Une gestion trop compliqué des comptes ou une ligne de commande merdique sur les postes de base. Bilan, les services tournent sous SYSTEM et non sur un compte spécialisé.
* Une gestion catastrophique des variables d'environnement avec un éditeur plus que pourris... heureusement on n'a de moins en moins besoin de modifier la variable Path par exemple.
* Une gestion très mauvaise de l'installation des logiciels... Aujourd'hui, chaque logiciel embarque son système de mise à jour (qui ne marche que si tu es admin) alors que l'ajout d'un simple fichier dans /etc/apt/sourcelist.d suffirait pour avoir un système de mise à jour décentralisé / centralisé fiable et sécurisé.
* Un système basé sur la prolifération des variables globales via la base de registre. Remarque, GNOME et les fanats des fichiers XML pour les config font prendre le même chemin à nos UNIX. Un exemple : il suffit de comparer la base de registre avant et après l'installation d'un logiciel Adobe pour voir la daube que peut être une base de registre...
*...
Dans ces points, si les développeurs faisaient proprement leur boulot, une partie ne serait pas la (pas exemple Adobe qui pollue la base de registre) mais en pratique, le système doit aider a avoir une pratique la plus claire et la plus simple possible. Le fonctionnement de Windows n'est pas des plus clairs si on n'est pas un spécialiste (sur ce dernier point, Linux suit la même voie lorsqu'on regarde par exemple la débilité de mettre en XML les fichiers de config de HAL... Il y a des exemples amusant sur debian en ce moment avec la configuration du clavier sous X pour ceux qui suivent leur planet !).
[^] # Re: But?
Posté par Guillaume Knispel . Évalué à 3.
Concernant /etc/apt/sourcelist.d, ça serait certes un progrès pour Windows mais c'est insuffisant en soit pour avoir une sécurité parfaite.
Concernant la base de registre ou équivalent gnomesque/kdiste, je ne sais pas si ça existe mais sans système similaire à un système de packaging traçant quel paquet a positionné quelle clef, c'est clair que c'est un joyeux bordel.
[^] # Re: But?
Posté par Samuel Thibault (site web personnel) . Évalué à 1.
Heingg ??
Et ctrl-alt-backspace c'est quoi ?
[^] # Re: But?
Posté par zebra3 . Évalué à 4.
Je ne le connais pas du tout, mais PackageKit ne permettrait-il pas de régler ce problème ? J'ai eu l'occasion de jeter un œil sur ConsoleKit, cela m'a l'air une solution excellente.
Concernant la base de registre ou équivalent gnomesque/kdiste, je ne sais pas si ça existe mais sans système similaire à un système de packaging traçant quel paquet a positionné quelle clef, c'est clair que c'est un joyeux bordel.
Pour GNOME c'est pas dur, vu que chaque dossier GConf correspond à un répertoire sur le disque, et les clefs du dossier dans un fichier XML; or dpkg comme RPM (et j'imagine que les autres aussi) savent à quel paquet appartient quel fichier. Donc c'est réglé.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: But?
Posté par Jean-Michel Philippe (site web personnel) . Évalué à 2.
C'est vrai mais ce serait quand même un énorme pas en avant parce que si chaque application vient avec de quoi se mettre elle-même à jour, ça veut dire que chaque application sait aller sur Internet et donc que chaque application amène son lot de trous de sécurité… Si ça c'est pas une grave erreur de conception !
[^] # Re: But?
Posté par pasBill pasGates . Évalué à -1.
Ah oui, pas avec apt-get car ils ne le supportent pas pour la plupart...
[^] # Re: But?
Posté par TeXitoi (site web personnel) . Évalué à 3.
Sinon, l'appstore, c'est un peu un apt pour proprio, et c'est pour ça que ça marche bien.
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Sous Linux, la mise a jour d'un logiciel propriétaire (type logiciel de calcul, par exemple matlab) signifie en pratique (cas debian) de faire la chose suivante :
- mettre à jour le dossier /opt/mon_logiciel_proprio
- mettre à jour /etc/sysprofile.d/mon_logiciel_proprio.bash
Voila. Après, je n'ai pas de logiciels proprio avec des données type base de données justement. Normalement, si c'est bien fait, on devrait avoir en plus à lancer
/opt/mon_logiciel_proprio/mise_a_jour_donnee.sh
La, effectivement, on rentre dans le spécifique et c'est parfois merdique (du fait d'une mauvaise conception du logiciel).
Un des premiers soucis des développeurs devraient être de savoir comment passer de la version n à la version n+1 facilement. Ce genre de réflexion dès le début de la conception permet d'éviter de rendre les mises à jour un enfer. Malheureusement, l'enfer signifie en pratique pas de mise à jour.
[^] # Re: But?
Posté par mats . Évalué à 3.
Un système basé sur la prolifération des variables globales via la base de registre. Remarque, GNOME et les fanats des fichiers XML pour les config font prendre le même chemin à nos UNIX. Un exemple : il suffit de comparer la base de registre avant et après l'installation d'un logiciel Adobe pour voir la daube que peut être une base de registre...
*/
Il y a tout de même de très bonnes raisons pour utiliser une base de registre. Exemple :
http://www.samba.org/~obnox/presentations/linux-kongress-200(...)
(pour ceux qui ont la flemme, Samba possède désormais une base de registre comparable à celle de windows pour stocker sa configuration et celle de ses partages. Ce mode de fonctionnement est pour l'instant facultatif mais sera généralisé (il l'est dans la 3.3). Les développeurs en attendent une plus grande flexibilité, une consommation des ressources moins grande qu'avec un fichier texte, une création de clusters enfin possible, des interfaces graphiques plus faciles à créer, ....)
Le Gconf de Gnome est aussi très flexible. Si un jour, une GPO apparaît sous Linux, ce sera tout à fait possible de le faire avec Gconf. Ce n'est pas parce que le backend réseau n'a, pour l'instant, pas été codé que ce n'est pas intéressant.
Après, ce que fait Adobe, c'est fort possible que cela soit crade.
[^] # Re: But?
Posté par B16F4RV4RD1N . Évalué à 5.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: But?
Posté par mats . Évalué à 2.
Historiquement, de nombreux développeurs de Samba ont utilisé Suse ; ils sont nombreux à avoir quitté le navire (volontairement, après l'accord MS-Novell, ou débarqués) depuis. Ils sont nombreux chez RedHat.
Pour ce qui est du copinage avec MS !!! Quel est l'un des premiers logiciels à être passé sous GPL 3 ?
Pour finir :
- base de registre ne veut pas dire qu'une action à distance ne sera pas possible, c'est même tout le contraire (voir les net conf, net rpc, ....)
- tu pourras toujours t'écrire des scripts utilisant les commandes net ... Ce n'est, au final, pas si différent d'un smb.conf.
- que fais-tu des arguments sur la charge des serveurs ou le clustering ?
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
La conf d'un serveur, c'est quelque chose de statique qui ne doit pas être modifier tous les 4 matins et qui ne doit pas se faire par le même canal que le serveur lui même. Tu te vois modifier la conf apache avec des simples requêtes http ! C'est vraiment vouloir faire la pars belle aux vers, cela me semble d'une conception ultra dangeureuse.
Un fichier de conf doit être lisible pour s'imprimer. Ainsi, il est facile de comprendre pour un spécialiste pourquoi cela ne marche pas. Faire 50 copies d'écran pour comprendre la conf d'un serveur est débile. D'ailleurs sous Windows, si cela ne marche pas, le technicien dé-installe le logiciel, le ré-installe et re-clickque avec son téléphone portable à l'épaule (c'est du vécu). C'est débilifiant comme démarche.
Pour le clustering ou la répartition de charge, il ne faut pas mélanger les problèmes de fonctionnement de serveur et de configuration. Je l'ai dis pour les firewall, qu'un cluster samba échange sur un AUTRE port ce genre d'info et que samba utilise un format binaire pour gérer cela, très bien. Tout ca n'a rien a voir avec de la configuration, c'est du fonctionnement qui se ré-initialise au démarrage.
Mélanger données de fonctionnement et données de configuration, mélanger le service rendus et l'adminstration à distance dans le même canal (port), tout cela pour moi est d'une dangeureusité qui ne mérité pas les bénéfices nul que l'on peut en tirer. C'est quand même pas bien dur aujourd'hui d'ouvrir un canal spécialisé, c'est pas bien dur de faire du stockage temps réel et un fichier à plat pour la configuration... A combien de ligne de code est le cout d'avoir un système unifié ? Quel est le cout d'orthogonaliser les choses pour limiter les risques énormes ?
Bien sur, à faire cela, on se coupe de l'AD de Crosoft et des GPO... et des consoles d'administration. Or l'objectif est de fusionner tout cela. Les gens de samba veulent rentrer dans l'abération de l'AD centralisé de Microsoft.
Moi cela ne m'intéresse pas le moins du monde.
[^] # Re: But?
Posté par pasBill pasGates . Évalué à 0.
Quel rapport ? Un ver si il controle ta machine, il peut utiliser n'importe quel canal, peu importe.
Un fichier de conf doit être lisible pour s'imprimer. Ainsi, il est facile de comprendre pour un spécialiste pourquoi cela ne marche pas. Faire 50 copies d'écran pour comprendre la conf d'un serveur est débile. D'ailleurs sous Windows, si cela ne marche pas, le technicien dé-installe le logiciel, le ré-installe et re-clickque avec son téléphone portable à l'épaule (c'est du vécu). C'est débilifiant comme démarche.
Visiblement tu n'as jamais utilise la fonction d'export de la registry. Devines ce qu'elle fait...
Quand au technicien qui ne sait rien faire d'autre que desinstaller et reinstaller, faudrait penser a prendre qq'un de competent comme technicien, c'est identique au gars qui desinstalle et reinstalle un rpm car il ne sait pas ou est le fichier de config du soft.
Bien sur, à faire cela, on se coupe de l'AD de Crosoft et des GPO... et des consoles d'administration. Or l'objectif est de fusionner tout cela. Les gens de samba veulent rentrer dans l'abération de l'AD centralisé de Microsoft.
Une aberration ? J'ai qqe dizaines de milliers d'entreprises voire plus qui ne sont pas du meme avis.
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
Donc oui, tout mélanger est une bétise.
Enfin, je parlais d'un ver qui cherche a rentrer et non a sortir... Mais je met aussi des règles en sortie sur mes serveurs.
Pour ce qui est de l'export de la base de registre, merci, je connais et heureusement que cela existe. Mais fait une simple action dans la configuration de Windows et dis moi ou cela se trouve dans le registre et cela sera complètement utilisable. Seule une toute petite partie de la base de registre est documenté, la grande majorité des clefs est totalement incompréhensible. Normal, il a été fait le choix de mélanger configuration et données de programme. Pour moi, c'est un défaut majeur dans la conception.
Quand à la problématique des techniciens, ta réponse est complètement à la rue. Tu passes un appel d'offre, la boite qui remporte le marché vient installer le produit et tu n'as pas le pouvoir de dire que tu veux tel ou tel technicien. Tu fait avec le technicien qu'on t'envoi pour la journée.
Pour les RPM, je suis parfaitement d'accord. Je ne suis pas fanatique des logiciels propriétaires même sous Linux car on retrouve les mêmes travers. Les techniciens n'y connaissent rien pour la plupart. Sans interface graphique, ils sont perdus. Si cela ne marchent pas, il dé-installe puis ré-installe... Bref, c'est le mauvais coté qui dérive sur Linux.
Concernant l'AD, je n'ai jamais dis que cela ne marchait pas. Les parts de marchés ne sont pas un témoin de la qualité car dans le cas présent, il y a un problème de MONOPOLE. En situation de monopole, toutes les cartes sont biaisés. Cependant, tout comme le sudo, l'AD a l'avantage de résoudre une problèmatique et il apporte une solution qui est finalement simple à mettre en oeuvre. Derrière les problèmes de conception et de sécurité, il permet a des milliers de postes d'être géré un minimum correctement. C'est donc une réponse pragmatique mais que personnellement je trouve beaucoup trop centralisé.
[^] # Re: But?
Posté par psychoslave__ (site web personnel) . Évalué à 8.
Bon de ce que je lit de la première page du papier que tu pointes, les deux «avantages» de l'utilisation de la base de registre sont
* une facilité de manipulation de la conf pour les programmeurs. Si c'est au détriment d'une facilité pour l'utilisateur, non-merci !
* les caractéristiques d'une base de donnée : gestion des accès concurrents etc. mais aussi, il devient bien plus difficile de faire une modification, tester et revenir en arrière avec le fichier de conf qu'on avait versionné ou dont on avait tout bêtement fait une copie de sauvegarde
Sans dire que l'approche de la configuration stocké dans un fichier plat est parfaite, je trouve qu'elle est plus pratique à bien des égards que l'approche où tout est géré dans une base de donnée.
[^] # Re: But?
Posté par CrEv (site web personnel) . Évalué à 3.
> gestion des accès concurrents
Et pour le coup c'est pas forcément rien... et c'est pas non plus à coup de cp que tu vas le gérer...
et pour l'histoire de versionner la conf ou d'en faire une sauvegarde souvent les autres systèmes ont des procédures de backup...
Non pas que je défende gconf & co mais tu aurais pu trouver mieux comme arguments...
[^] # Re: But?
Posté par CrEv (site web personnel) . Évalué à 1.
[^] # Re: But?
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Prenons la gestion de la concurrence : combien d'admin triturent généralement un même fichier de conf en même temps ?
Ce n'est pas du tout impossible sur un gros parc bien sûr, et je peux me tromper, mais ça me semble tout de même relever de l'incident ponctuel. Un simple message «le fichier à été modifié depuis sa dernière lecture» dans n'importe quel éditeur de texte permet de repérer et gérer manuellement ce genre d'incidents. Maintenant peut être que je me trompe et qu'il y a des parcs où des centaines d'administrateurs passent leur temps à modifier des fichiers de conf de leurs serveurs, auquel cas je veux bien ne serais-ce qu'un exemple.
[^] # Re: But?
Posté par Guillaume Knispel . Évalué à 2.
T'as pas honte de faire apparaître de telles visions d'horreur dans l'esprit de tes lecteurs ?
[^] # Re: But?
Posté par pasBill pasGates . Évalué à 4.
Tu es en train de me dire que les ACLs c'est mal ?
Pas d'équivalent des bits suid ou du sudo. Bilan, c'est merdique de déléguer une partie de l'administration du poste.
Ah suid, oublions vite que c'est une vraie plaie niveau securite hein car il ouvre la porte admin toute grand si il y a une faille dans un soft suid...
Windows a un systeme de privileges, soit t'as l'autorisation d'effectuer l'operation soit tu ne l'as pas, point, pas d'execution arbitraire de code sous un autre utilisateur.
Une gestion trop compliqué des comptes ou une ligne de commande merdique sur les postes de base. Bilan, les services tournent sous SYSTEM et non sur un compte spécialisé.
Il n'y a aucun rapport entre la ligne de commande et ce sous quoi les services tournent, tu m'expliqueras...
Une gestion catastrophique des variables d'environnement avec un éditeur plus que pourris... heureusement on n'a de moins en moins besoin de modifier la variable Path par exemple.
Il te faut un editeur pour changer une variable d'environnement ?!? Tu m'expliqueras...
Une gestion très mauvaise de l'installation des logiciels... Aujourd'hui, chaque logiciel embarque son système de mise à jour (qui ne marche que si tu es admin) alors que l'ajout d'un simple fichier dans /etc/apt/sourcelist.d suffirait pour avoir un système de mise à jour décentralisé / centralisé fiable et sécurisé.
Ca pourrait s'ameliorer oui, mais ca n'a rien a voir avec la securite de l'OS lui-meme.
Un système basé sur la prolifération des variables globales via la base de registre.
Rassures moi, tu sais la difference entre les hives specifiques a un utilisateur et les hives globales ?
Quand a ce que fait Adobe, tu prefererais qu'ils modifient des fichiers textes a la degueulasse dans /etc ? Tu m'expliqueras la difference.
Oh, et tu passeras le message aux gars de Samba, ils semblent avoir un avis different...
Le fonctionnement de Windows n'est pas des plus clairs si on n'est pas un spécialiste (sur ce dernier point, Linux suit la même voie lorsqu'on regarde par exemple la débilité de mettre en XML les fichiers de config de HAL... Il y a des exemples amusant sur debian en ce moment avec la configuration du clavier sous X pour ceux qui suivent leur planet !).
Je te l'accorde, celui qui ne cherche pas, ne fait pas un minimum d'effort ecrira un soft de merde. Mais c'est independant de l'OS ca hein, parce que celui qui ne fait pas l'effort de comprendre, il va rien comprendre au contenu de /etc je te le garantis.
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
La solution dans Linux de mettre un système type SeLinux pour les spécialistes et un système simple par défaut me semble au final plus simple car les personnes l'utilisent.
Pour ce qui est des suid, un bogue est un bogue mais rassuses-toi, il y en a aussi dans Windows et l'élévation de droit existe aussi. Il n'empêche, ce système est simple et a prouvé qu'il marche.
Pour ce qui est des services, pourquoi tournent-ils sous SYSTEM ? Je les fais tourné sous SYSTEM parce que c'est en partie merdique de créer un compte en ligne de commande, que les scripts bat ou vbs sont merdiques et donc les gens vont au plus simple.
Pour ce qui est des variables d'environnements, qui n'a pas bidouiller la valeur d'une variable dans les propriétés du poste de travail ? Par exemple la variable Path ? Cette interface est une des pires que je connaisse.
Je connais pas trop mal le principe des ruches et je peux même te dire que le compte SYSTEM n'en a pas et que cela fout la merde pour un certain nombre de programme (par exemple psexec qui stocke l'eula dans la ruche, mais des trucs qui marche sous le compte admin et pas SYSTEM, il y en a plein...). Que tu est une ou des ruches, ce sont toujours des variables globales. Tu peux comparer la taille du /etc et celle de la ruche du system, je serais amusé de voir leur taille respective...
Pour Adobe, sous Linux, son installation ne fout pas le bordel dans /etc et sous Windows oui. C'est aussi simple que cela, il y a une philosophie de l'environnement sous UNIX qui demande a ne pas faire le bazard chez le voisin. Et c'est globalement respecté ! Je n'ai donc pas dis que l'OS est complètement merdique, je dis que si un grande majorité de développeur font des trucs merdiques, alors l'OS doit se remettre en cause pour essayer de comprendre pourquoi et modifier son comportement pour éviter cela dans le futur. Depuis les débuts de Windows 2000, c'est mieux mais ce n'est pas encore cela. Et je pense que sous Linux, il y a une tendance dangeureuse à prendre la voie de la complexité inutile, j'ai pris l'exemple de GNOME mais c'est effectivement le cas de samba...
Une partie des développeurs autour de GNU/Linux travaille maintenant pour des boites dont l'objectif est de vendre des usines à gaz a installer pour des techniciens cliclodromes... Donc, il faut des cliclodromes pour configurer, des interfaces graphiques de partout, des consoles d'administration... Donc par derrière, le fichier XML ou la base de registre sont parfait. On stocke le bordel du cliclodrome la dedans et on est content.
Je ne suis pas de ce mouvement et je propage/controle mes fichiers de config via cfengine sur mon parc sans soucis. Tout cela est versionner dans subversion. Bref, rien que des outils orthogonaux, simple et robuste. Modifier la configuration d'un logiciel ne doit pas être quelque chose qui a à voir avec le temps réel, si c'est le cas, on n'est plus dans la configuration mais dans la partie données/stockage de l'application. Pour faire un firewall clusterisé, il faut bien évidement que les firewall s'échangent en temps réel les sessions et les états. Ceci n'est pas de la configuration du firewall donc un format binaire, XML, registre... pour faire cela est tout a fait normal.
A mon sens, les gens de samba vont mélanger configuration et partage de fichier (et fonction d'impression...) sur le même port. C'est une très mauvaise démarche. Cela me semble à l'opposé de la stratégie UNIX de la simplicité mais surtout de l'orthogonalité. Qu'un cluster samba échange entre-eux des informations de type redondance, RAID... très bien, mais cela n'a rien a voir avec de la configuration (ni le partage effectif d'ailleurs).
[^] # Re: But?
Posté par Troy McClure (site web personnel) . Évalué à 1.
Entièrement d'accord c'est imbittable, et assez frustrant de se battre contre ce truc pour arriver à modifier un fichier ou a le supprimer (avec vista qui dit "ouin j'y arrive pas, voulez vous recommencer")
[^] # Re: But?
Posté par Troy McClure (site web personnel) . Évalué à 4.
Comment ça tu n'aimes pas editer une ligne 1000 caractères dans une fenetre non redimensionnable de 50x15 pixels ????
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Non vraiment, les clickodromes sont conçus par des spécialistes des IHM !
[^] # Re: But?
Posté par pasBill pasGates . Évalué à 1.
Dis-moi plutot ce que ta grand-mere a a faire des ACL. En quoi aurait-elle besoin d'y toucher ? Elle download des fichiers, elle sauve des fichiers depuis ses applications, en quoi a elle besoin d'y toucher ?
Ensuite, un admin ou un power user en aura besoin, mais tu m'excuseras, un admin qui ne sait pas gerer des ACLs devrait changer de carriere.
La solution dans Linux de mettre un système type SeLinux pour les spécialistes et un système simple par défaut me semble au final plus simple car les personnes l'utilisent.
Certainement pas, SeLinux ne remplace pas les ACLs et est un systeme assez limite(sauf si on veut vivre un enfer) et la gestion des ACLs est litterallement pourrie dans Linux du fait du double systeme et du fait que la plupart des softs n'ont jamais ete fait pour les gerer.
Pour ce qui est des suid, un bogue est un bogue mais rassuses-toi, il y en a aussi dans Windows et l'élévation de droit existe aussi. Il n'empêche, ce système est simple et a prouvé qu'il marche.
Oh oui il est simple, tu pourrais aussi leur filer le mot de passe admin, c'est simple aussi.
Combien des softs que tu mets en suid ont ete developpes avec l'idee qu'ils seraient suid ? Un petit groupe et c'est tout, les autres n'ont jamais ete prevu pour et la securite n'a jamais ete un mot d'ordre car ces softs etaient senses etre utilises sous un compte admin par un utilisateur de confiance, pas en tant que suid, suffit qu'ils gerent mal les parametres en ligne de commande et hop, buffer overflow et passage en admin.
Pour ce qui est des services, pourquoi tournent-ils sous SYSTEM ? Je les fais tourné sous SYSTEM parce que c'est en partie merdique de créer un compte en ligne de commande, que les scripts bat ou vbs sont merdiques et donc les gens vont au plus simple.
C'est merdique de creer un compte en ligne de commande ?!?
net user [utilisateur] [motdepasse] /add
super complique... et j'ai pas touche WMI encore.
Si tu veux des options plus complexes, demandes je te files la ligne de commande.
Pour ce qui est des variables d'environnements, qui n'a pas bidouiller la valeur d'une variable dans les propriétés du poste de travail ? Par exemple la variable Path ? Cette interface est une des pires que je connaisse.
Dis-moi donc, quel utilisateur novice va avoir besoin de faire cela un jour ? Aucun.
Un utilisateur avance ? Ben il y a plusieurs methodes :
a) T'installes les support tools et t'utilises setx.exe
b) Tu vas dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment et tu changes la variable
Je connais pas trop mal le principe des ruches et je peux même te dire que le compte SYSTEM n'en a pas et que cela fout la merde pour un certain nombre de programme (par exemple psexec qui stocke l'eula dans la ruche, mais des trucs qui marche sous le compte admin et pas SYSTEM, il y en a plein...). Que tu est une ou des ruches, ce sont toujours des variables globales. Tu peux comparer la taille du /etc et celle de la ruche du system, je serais amusé de voir leur taille respective...
Elles n'ont _rien_ de global, la ruche de l'utilisateur toto, elle est locale a lui, rien de ce qui est stocke dedans ne sera accessible ou visible a qui que ce soit d'autre. Il y a des ruches globales oui, vu que les parametres du systeme sont globaux, tout comme /etc est global.
Quand a la taille, vu l'espace que prennent ces fichiers de config dans /etc la comparaison serait interessante.
Une partie des développeurs autour de GNU/Linux travaille maintenant pour des boites dont l'objectif est de vendre des usines à gaz a installer pour des techniciens cliclodromes... Donc, il faut des cliclodromes pour configurer, des interfaces graphiques de partout, des consoles d'administration... Donc par derrière, le fichier XML ou la base de registre sont parfait. On stocke le bordel du cliclodrome la dedans et on est content.
Et tu veux quoi a la place ? Des petits executable simplistes en ligne de commande, impossible a utiliser par le pekin moyen et insuffisants pour faire son boulot correctement ?
Faudrait penser a revenir dans le monde reel hein, si les gens developpent les softs comme cela c'est parce que les gens les preferents aux softs en ligne de commande qu'il faut chainer les uns aux autres.
Modifier la configuration d'un logiciel ne doit pas être quelque chose qui a à voir avec le temps réel, si c'est le cas, on n'est plus dans la configuration mais dans la partie données/stockage de l'application. Pour faire un firewall clusterisé, il faut bien évidement que les firewall s'échangent en temps réel les sessions et les états. Ceci n'est pas de la configuration du firewall donc un format binaire, XML, registre... pour faire cela est tout a fait normal.
Et tu fais comment pour modifier un soft qui ne doit pas s'arreter ?
Si t'utilises un fichier texte, t'as aucune validation du contenu, tu peux ecrire n'importe quoi n'importe ou, aucune atomicite des valeurs, faut relire tout le fichier, ...
Les gars de Samba sont pas des idiots non plus, ils ont une legere experience du domaine, et ils ont choisi la methode registry pour une bonne raison.
[^] # Re: But?
Posté par GutsBlack . Évalué à 7.
C'est surement le but visé, mais même si ils ne l'atteignent jamais je trouve ça intelligent de décortiquer un système concurrent et de l'analyser. La plupart des logiciels, du moment qu'ils sont libres, sont interessants parce qu'ils permettent d'apprendre et de tester différentes façon de procéder.
ReactOS est un projet lourd mais nécessaire à la compréhension d'un système Microsoft Windows.
[^] # Re: But?
Posté par GEDsismik (site web personnel) . Évalué à 1.
ok, je sors --> []
# CC
Posté par Mehdi Saada . Évalué à -10.
Ca me met en rogne.
Et l'autre ... Depuis quand la structure de windows est interessante ? C'est merdique et codé avec les pieds .
[^] # Re: CC
Posté par GEDsismik (site web personnel) . Évalué à 7.
L'intérêt est que :
- Les boites qui ont des applis métiers qui tourne que sur NT4 par exemple pourront avoir un OS sans cout de license, mise à jour et surtout... Libre.
Bénéfice : coût réduit de migration, plus de lien avec Microsoft, plus de sécurité, libération de machines
- Combien de personnes à qui j'ai parlé de Linux m'ont dit "Ben écoute, mon ordi me sert que pour jouer et la bureautique. Quand tous les jeux seront dispos sous Linux, je l'installerais à la place de mon Windows cracké". Si ReactOS devient suffisamment rapidement stable, je pourrais très bien leur dire : "Revient dans la légalité, prend-ça". Pense aussi à ceux d'entre nous qui garde un multiboot windows pour les jeux.
Bénéfice : Développement d'une alternative (comme FF contre IE), réduction de l'influence de Microsoft, libération de machines
Le principal frein que je trouve quand je veux diffuser Linux, ce sont les offres logiciels, principalement applis spécifiques et jeux. Si nous avons une alternative, nous pouvons diffuser un OS Libre, faire prendre conscience aux gens qu'il existe autre chose que Windows, faire prendre conscience aux éditeurs de soft/pilote qu'il existe autre chose que Windows.
De plus, avoir un "Windows Libre", ça serait avoir un OS compatible win32 sur lequel on aurait accès au code source, et, pourquoi pas, aller au dela. Genre "cette fonctionnalité existe dans ReactOS et pas dans Windows, pourquoi je prendrais Windows ?".
ReactOS est un projet que je suis avec attention depuis plusieurs années. Je pense qu'il a un réel intérêt. J'attend avec impatience la première release stable.
[^] # Re: CC
Posté par Akela_NDE . Évalué à 2.
ReactOS permet de lever ces freins au libre en environnement professionnel, puisqu'il s'agit d'un système capable de faire tourner les applis écrites pour win$, et similaire à NT/XP en termes d'interface, ce qui n'est pas un point à négliger quand on connait le niveau de certains utilisateurs qui, si on ne les forçait pas à travailler sur informatique, feraient encore tout sur papier ...
Bref, avec une release stable de ReactOS (et des boîtes proposant du support, évidemment), plus personne n'aura d'excuse pour ne pas passer au libre.
[^] # Re: CC
Posté par C. OB (site web personnel) . Évalué à 3.
Vieilles Cartes GPIB (ou autre) non supportées par les derniers XP/Vista, de vieux logiciels proprio pour programmer des microcontrolleurs avec le port série ou parallèle qui ne marchent plus sur les nouveaux windows, les outils de reprogrammation de téléphone..
Tout ça ne peux marcher ni avec wine, ni sous machine virtuelle, et comme microsoft ne fourni plus ni licence ni support pour ces licences...
Dans ce contexte, ReactOS serais très bien.
(Je ne sais pas si il est compatible avec les *pilotes* windows, par contre, pour les cartes spécifiques).
[^] # Re: CC
Posté par Kerro . Évalué à 5.
Beaucoup d'entreprises ou d'administrations utilisent win$ XP, ne veulent pas passer à Vista pour des questions de coûtJe crois que ce n'est pas pour des questions de coût mais plutôt que Windows XP fonctionne très bien pour ce qu'on en fait, alors que Vista ne fonctionne pas vraiment bien, c'est le moins qu'on puisse dire :-)
Passer à Linux est par contre bien souvent une question de coût: beaucoup de temps à passer pour apprendre/comprendre. C'est ce qui rebute la plupart des décideurs (à tort ou à raison, la question n'est pas là).
[^] # Re: CC
Posté par Grunt . Évalué à 2.
A part "faire tourner des logiciels Windows sans payer de licence Windows", je n'en vois pas en fait.
Si un logiciel ne fonctionne que sous Windows, il y a de grandes chances pour qu'il ne soit pas libre. L'utilisateur qui se retrouve dans cette situation n'est pas alors "un libriste convaincu" (un "intégriste", si vous n'êtes pas d'accord avec lui), sinon il n'utiliserait pas un logiciel propriétaire conçu pour Windows.
A ce moment-là, son seul (?) critère de choix restant est le prix. Non?
J'ai lu plus haut les remarques concernant la sécurité, mais (malheureusement) ça ne semble pas être une des préoccupations majeures des utilisateurs Windows.
Peut-être que ReactOS a un marché de niche en entreprise, là où le coût des licences se multiplie avec le nombre de postes, où la nécessité de faire tourner certains logiciels propriétaires passe bien avant la question de savoir s'ils sont libres, et où la sécurité a son importance. Mais je ne vois pas de marché grand public.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: CC
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: CC
Posté par Grunt . Évalué à 3.
Microsoft reste le leader qui oriente le développement de la plateforme win32, et ReactOS suit ses traces avec un temps de retard.
Je doute qu'un éditeur de logiciels pour Windows vérifie la compatibilité avec ReactOS de ses binaires avant de les distribuer.
Au contraire, ReactOS peut favoriser le monopôle de Windows.
Il y a un projet qui lui ressemble: swfdec, plugin destiné à lire les applications Flash.
Tout comme ReactOS, il est l'alternative libre à un logiciel propriétaire.
Tout comme ReactOS, presque personne ne l'utilise.
Tout comme ReactOS, il a une guerre de retard sur son "modèle".
Et j'ai souvent vu l'existence de swfdec servir d' "excuse" pour justifier l'utilisation de Flash: "Te plains pas, si t'aimes pas le plugin Flash y'a swdec, qui est libre, disponible pour ton architecture, et qui te permet aussi de lire les mêmes applications."
Je redoute que l'existence de ReactOS serve de la même façon d'excuse au développement "pour Windows seulement" de binaire propriétaires.
C'est un peu le cas avec Wine: si les gentils utilisateurs se cassent la tête à faire marcher nos logiciels avec Wine ou ReactOS, pourquoi on leur proposerait une autre solution?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Accélération matérielle
Posté par Octabrain . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.