Aller au contenu

actaruss

INpactien
  • Compteur de contenus

    41
  • Inscription

  • Dernière visite

  • Jours gagnés

    1

Tout ce qui a été posté par actaruss

  1. C'est gentil de faire une réponse sérieuse, mais on verra pour les détails quand on aura terminé le noyau. J'attends la suppression du topic de la part d'un véritable admin (un qui ne soit pas un gamin). Bien noté pour le nom du projet, de toute façon c'est sans doute temporaire.
  2. Tu es admin non ? Comporte-toi en adulte. Détruis ce topic stp et on en parle plus.
  3. Non, car elles sont "redistribuables", tout comme certains produits microsoft. Wine inclu des DLL de directX dans ses releases d'ailleurs. Sinon on fera du RE. Et je peux savoir comment tu juges mes connaissances globales acquises depuis de nombreuses années sur un topic à la con ? Un topic où tu n'as rien à dire d'ailleurs. Bon, si un modo veut bien fermer et même supprimer ce topic, je l'en remercierais. Visiblement ya aucune idée bas-niveau à proposer vu que personne ne semble s'y connaître assez sur le fonctionnement d'un noyau. On en reparlera quand on aura finit le noyau, sur un site où je pourrai moi-même modérer les trolls. Me casse moi.
  4. Bah, tous les ans environ, y'a un petit gars comme toi qui balance un projet de ce genre... On en a deja vu 2 ou 3 avant toi dont MultideskOS est le plus celebre. Les gars comme toi et ton pote n'ont AUCUNE idee de ce que represente la somme de travail necessaire pour faire un OS comme Linux ou Windows. D'ailleurs, vous n'avez AUCUNE idee de ce qu'est un OS et des differentes parties qui le compose. Rien que le fait de melanger joyeusement Bureau, Noyau, Applis, Systeme de Fichiers, etc denote clairement un manque effroyable de competence sur le sujet. Je comprends ton scepticisme. Déjà j'ai dit qu'on allait pas tout reprendre de 0. Les sources de nux sont dispo, et on s'en sert. Après le projet mettra 1 ou 2 ans à sortir. Peut-être qu'on sera découragé devant les difficultés, ou peut-être que non. Dans tous les cas les commentaires de ce genre ne servent à rien. En plus, j'ai prévenu dès le début => "Attention, ce sera peut-être un vapoware". Le projet est né de l'idée d'injecter du code ASM directement dans le noyau. Ce topic sert de boite à idée. Pas de défouloir pour essayer de tuer dans l'oeuf ma motivation.
  5. Ce topic part en couilles... Ils ont vraiment besoin de s'exprimer sur PCI... Je pensais que les comz des newz suffisaient. Lol. Joli.
  6. Tu es ridicule. Ton post montre que tu n'as rien lu du topic. Tiens, toi qui est si bien renseigné : show us the code! Comme ça on pourra refiler ça à Linus et toute la troupe histoire qu'ils ne soient plus violés après. J'ai vraiment besoin de te montrer le code en ce qui concerne le concept du double-clique, du clique-droit, ou du menu contextuel ? Ou encore de la barre de progression ? Je ne vois pas trop à quoi ça t'avancera. Bon, je n'ai pas de temps à perdre avec des trolls dont l'intelligence atteint difficilement celle de la morille de mer du nord. Si vous n'avez aucune idée à proposer, je vous ignorerai. Je n'ai ni le temps ni le courage de me lancer dans des débats stériles.
  7. Le "un peu" était là pour ironiser, on est d'accords... Sinon pour ce qui est du reste, il faudra que notre noyau le fasse aussi alors... Tient à ce propos, j'avais une petite question à poser : On voudrait bien entendu arriver à supporter un max de FS disponibles (FAT, NTFS, HFS et HFS+, ext, Reiser) pis on comblera avec des modules pour le reste. On va pas se faire chier, on va reprendre Linux pour ça. On devra prendre ça en charge très tôt puisqu'il est prévu, pour des raisons de sécurité, que seul le noyau principal ait accès en écriture sur les fichiers. Je voulais donc savoir, vis-à-vis des expériences que vous en avez, quel est le meilleur système selon vous ? Moi j'aime bien ext3 mais je le trouve craignos niveau défragmentation. ext4 intègre (enfin) un défragmenteur mais quelqu'un sait-il ce qu'il vaut ? (Parce que quelque soit le système, la défrag, à force de supprimer et créer, on ne peut y échapper...) La compatibilité Windows nous pousse à utiliser NTFS nativement par défaut car il faudra que l'utilisateur puisse par exemple lire ses disques durs externes sous un Windows, mais NTFS, on ne l'aime pas beaucoup, d'autant plus qu'on a que NTFS-3G pour cela (il supporte pas chiffrement et compression d'ailleurs)... Que faire ? Qui plus est, NTFS apparaît comme pas super pratique pour le cryptage des disques durs, des partitions et tout ce qui est anonymat fondamental. On pourrait laisser décider lors du choix du système lors du formatage du disque dur ? Mais comment faire pour l'utilisateur "de base" qui ne sait pas lire et juste cliquer sur le bouton le plus voyant ? On propose quoi par défaut ?
  8. Pour moi, tu vas rire, c'est le concours de l'internat de médecine. J'ai commencé dans l'info mais j'ai radicalement changé de branche tout en gardant un pied dedans, je m'oriente probablement vers l'imagerie et secteurs associés, l'info est en plein boum là-dedans. Je bosse l'info comme passion et je suis le "disciple" du boss (le chef du projet). Le boss il fait polytech'nice sophia, j'en dirai pas plus parce qu'il tient à son anonymat. Tout de suite, ça en impose grave Polytechnique. Enfin ça reste "Polytech'Sophia" en fait. Pas du tout Polytechnique (l'X) Suis bien placé pour le savoir, j'ai fait la même mais à Nantes Ça s'intègre un peu plus facilement que la vraie Enfin c'est un "détail un peu HS". Juste qu'il faut pas confondre Polytechnique ne fait pas d'informatique de pointe ou d'ingénierie réseau à ma connaissance, mais je peux me tromper. A ma connaissance, les ingé de l'X sont plus polyvalents mais pas supra-spécialisés. Nice est l'un des 4 pôles (avec Dijon et je sais pas les 2 autres) à proposer des formations réseau / informatique / électronique. Ce n'est donc pas si mal... Mais c'est loin derrière moi tout ça, je peux me tromper.
  9. Non. C'est pour ça que je réponds pas aux trolls. Je voudrais des idées. Ma hantise, c'est qu'on oublie bêtement une super bonne idée sur le bas-niveau qui aurait été mirifique... C'est une brute du coding, ça c'est indéniable. Le boot est fait sinon, du moins la première partie. Et on développe le noyau en même temps. Et un boot, quand il s'agit de le faire de manière complète et en ASM, ce n'est pas aussi facile que ça, et surtout c'est long. Grub contient un peu plus que 3000 lignes et il n'a pas été fait en 1 mois... Pour tout te dire, moi non plus. Tant que je vois pas le noyau complet, j'y crois qu'à moitié, car ce projet me semble complètement démentiel. Quant à la légalité, c'est surtout pour ça que le boss m'a contacté, parce que j'aime bien l'ASM et parce que ma soeur est en DJCE de droit (c'est une brute). On va de toute façon devoir essayer de rendre le truc légal, on ne peut pas faire autrement. Je pense qu'il faudrait inclure la possibilité de graver un OS installable directement depuis un OS installé, et qu'en parallèle il faudra la possibilité de maintenir tout à jour via un "Phoenix Update" paramétrable selon plein de trucs, comme un gestionnaire de packages mais avec des fonctionnalités supplémentaires... Cela permettra aux gens de s'échanger entre eux des trucs propriétaires... Nous, dans la distrib, on pourra mettre des trucs redistribuables de Microsoft, mais pour les drivers et surtout les vieilles librairies (vieilles DLL de DirectX) on va être bien emmerdés... Au pire on fera du RE et on réécrira des DLL mais ça va prendre un temps fou. De toute façon Microsoft possède tellement de brevets complètement aberrants qu'il est impossible d'être inattaquable vis-à-vis d'eux. Quand Microsoft dit que Linux viole 147 brevets de Microsoft, c'est effectivement vrai. Mais après faut voir les brevets... Je pense qu'on aura pas le choix, faudra tout mettre en GPLv3 et espérer que la communauté du libre nous défendra au pire. D'où l'idée de rester anonymes d'ailleurs... (faudra prendre un serveur en russie ou en pologne...) (Faudra que je pense à foutre en l'air ce topic quand le site sortira)
  10. C'est pas grave, je voulais juste être sûr que l'on ne rate pas d'idées lumineuses au passage, c'est pour ça que j'ai créé le topic pour me donner bonne conscience. Je pense que les idées viendront à la pelle dès qu'on sortira la version test du noyau, d'ici 1 ou 2 ans.
  11. Oui ça existe. Ca fait quelques optimisations. Encore que je n'aurais pou du en parler puisqu'il n'y en aura pas tellement besoin. Pas besoin de compilateur, tout sera géré à la main. OK, si tu veux, en théorie oui c'est une surcouche. Mais tellement fine... S'il est écrit en ASM, qu'il est plus optimisé, et plus adapté au matériel récent, ce sera meilleur... Maintenant tu as raison, c'est vrai que le noyau monolithique reste le meilleur choix en terme de perfs (dans la théorie pure, après il y a tellement de paramètres qui rentrent en compte...), mais il s'agit ici d'inclure une compatibilité windows. Wine est une couche supplémentaire qui transcrit les fonctions DirectX en fonctions OpenGL (ou d'autres librairies associées mais on va pas rentrer dans le détail...). Ici, il s'agit de réécrire directement les fonctions noyaux de Windows pour prendre en charge les drivers afin que DirectX soit nativement prit en charge, comme sous Windows. Il ne s'agit bien entendu surtout pas "d'émuler" ou de se taper toutes les fonctions DirectX à éplucher comme ils le font sous Wine, on est pas fou non plus... Il y a pas mal de fonctions noyau Windows (quelques milliers), mais la plupart sont bien documentées sur la MSDN. Quant au reste, on aura notre noyau magique et le décompilateur (je sais, c'est illégal, toussa, bla bla). Il s'agira donc de faire tourner l'ensemble Jeux => DirectX => Noyau + Drivers => Carte graphique directement sans intermédiaire. Le seul obstacle qui rend cela impossible sous Linux c'est justement la structure du noyau, d'où notre choix d'un noyau hybride.
  12. Je crois que l'on a du avoir un petit quiproquo sur l'emploi du "un peu", mais que dans l'ensemble on est d'accord. Pour moi, tu vas rire, c'est le concours de l'internat de médecine. J'ai commencé dans l'info mais j'ai radicalement changé de branche tout en gardant un pied dedans, je m'oriente probablement vers l'imagerie et secteurs associés, l'info est en plein boum là-dedans. Je bosse l'info comme passion et je suis le "disciple" du boss (le chef du projet). Le boss il fait polytech'nice sophia, j'en dirai pas plus parce qu'il tient à son anonymat.
  13. Pas encore. On aime pas présenter les projets en cours. Le topic sert juste à récupérer des idées. Si vous avez des idées pour le bas-niveau, allez-y. Sinon je vous laisse, entre le PFE sur la virtualisation et un concours à préparer, on est un peu occupé sur autre chose en ce moment, d'où le délai de sortie du noyau... (Nom de Dieu, il est 3h52, c'est pas possible, ils dorment jamais sur PCI ?!)
  14. Par générique, je voulais dire un driver officiel bien supporté par linux (GeForce 9800 GT avec driver linux 32 bit 177.80). 1) le driver en question est pas libre, il n'est pas officiel dans le référentiel "kernel linux" (ya quand même un joli blob dedans), donc je vois mal en quoi il est bien "supporté" par Linux 2) s'il marche très bien sur certaines générations, il est clairement BEAUCOUP plus lent sur les 8*** et 9***. So. J'ignorais. Autant pour moi. Le boot de compiz. Il nécessite de la RAM et du CPU, tout naturellement. Quant à la gestion des effets, il nécessite un peu de RAM aussi, le GPU prenant bien entendu la partie calculs en charge, je doute que tout soit distribué sur la RAM-GPU. Et puis tout ce qui bouffe un peu de CPU bouffe un peu de RAM aussi, ça m'étonnerait que compiz soit "0-RAM" dans son fonctionnement...
  15. Par générique, je voulais dire un driver officiel bien supporté par linux (GeForce 9800 GT avec driver linux 32 bit 177.80). La RAM et le CPU, pour compiz non, mais pour son boot et pour la gestion (graphique) des applications, un petit peu quand même (Je précisais surtout pour parler du boot, parce que si j'avais dit 500 MHz et 512 Mo, je doute que tout mon PC (dont Compiz) aurait tourné pareil...)
  16. Donc en fait t'avais aucun argument et tu te permets de répandre le FUD sur la qualité du code de Compiz, alors que les drivers graphiques sont potentiellement en cause :/ Enfin bref. Si tu veux aider les devs compiz-fusion, tu peux toujours aller les voir sur IRC (Freenode/#compiz-fusion-dev), ils seront probablement très heureux de recevoir ton aide. Bon en fait j'avoue, j'ai répété bêtement les propos du boss qui beugle sans arrêt sur la qualité du code de compiz (en même temps, le boss il voudrait voir de l'ASM et du C bas-niveau partout, il estime que le C++ c'est pour les tarlouzes) Sinon t'inquiète pas mes drivers graphiques sont relativement récents et génériques, ils ne sont pas en cause, et j'ai 3 Go de RAM sur un dual core... Je ne me le permettrait pas sinon...
  17. Un ami et moi, nous avons décidé de créer un nouvel OS. Phoenix pour "Environnement d'Exploitation Serviable Populaire Non Issu de linuX" Popular Helpful Operating Environment Non Inherited from linuX est le nom (temporaire ?) du projet. Si vous avez une meilleur idée de nom ou d'acronyme pour Phoenix, n'hésitez pas, mais entre Phoenix et Cortex, nous tenons à garder ce genre... Je ne peux vous garantir que ce ne soit pas un vaporware tant que le projet, débuté depuis 1 mois, n'aura pas prit plus d'ampleur, c'est à dire tant que nous n'aurons pas crée un site internet (prévu pour dans 1 à 2 ans environ, nos études nous bouffant pas mal de temps), et tant que la première version du noyau ne sera pas sortie. Je place ce sujet sur le forum en vue de le faire fructifier. Libre à un modo de l'épingler si ce topic prend de la consistance. Le but de ce topic est une boîte à idées. Postez ici toutes les reproches à Linux / Windows, et tout ce que vous aimeriez voir dans un OS. Je ne mettrai rien de technique sur ce topic dans la mesure où je veux les idées de tout le monde, même celles qui semblent les plus bêtes et les plus simples. Idée : En gros : Nous en avons marre des OS actuels. - Windows est un système d'exploitation commercial fait par des gens pas super-bons en info, mais qui a l'avantage d'être tourné vers le néophyte qui n'y connaît rien. Commercial en somme. Avantages * Il est bien présenté, avec une interface graphique correcte. * Il a l'avantage d'être simple d'abord. * Compatible avec un grand nombre d'applications, et surtout avec les jeux. * Euh... Il est beau. * Il est beau, ça c'est sûr... Et... Euh... Euh... Inconvénients *Sécurité déplorable, puisque Microsoft fait du partenariat avec les boîtes anti-viri qui produisent elles-mêmes la majorité des viri. La sécurité ne sera donc jamais correcte pour des raisons commerciales, en dépit de tout ce que Microsoft a toujours raconté à chaque lancement d'un nouveau Windows. * Il ne laisse pas de droits d'accès, il verrouille trop de choses (notamment les couches comme la 2, le réseau et Windows, c'est pas l'extase...). * Les questions de priorité des comptes sont mal gérées, chacun débute sur un compte admin, ce qui est une très grosse erreur. * L'installation du système est très incomplète, les questions posées et les composants installées et réglages devraient être bien plus nombreuses. * Le système des DLL est catastrophique, chaque application place des DLL et des drivers n'importe où, ce qui abouti à la polution de system32 et de la base des registres (winrot) * Le système de base des registres est un enfer, la configuration devrait être dispatchée dans des fichiers. (par exemple, chaque fenêtre devrait avoir son fichier de config avec taille, position, etc.) * Désinstallation très mal gérée, elles sont souvent très sales, il faudrait un système qui se passe des installations. Il faudrait que le script des installations soit réutilisé pour désinstaller, et qu'il n'y ait qu'un dossier à supprimer. La notion même d'installer un programme telle qu'elle est définie sous Windows est une hérésie informatique. - Linux est un système d'exploitation de vieil informaticien, fait par des gens pas non plus super-bons en info (le C bas niveau est bien maîtrisé, mais le niveau de maîtrise du C++ et de l'ASM est catastrophique), mais qui a l'avantage d'être très modulable. Défaut majeur : Il ne faut jamais taper dessus sur un forum, sinon on se fait latter les couilles. Mais si Linux était si bien que ça, il n'aurait pas que 1% de parts de marché. Avantages * Il a l'avantage d'être rapide, bien mieux pensé fondamentalement en terme de perf et de sécurité. * Avantage des standards ouvert, créer un pilote est enfantin tant qu'on a les spécifications. * Très bon système des gestion des paquets, pas de désinstallations sales, dépendance bien gérées. * Bonne sécurisation des applis avec le système SandBox ou le fait que chaque application ne s'exécute que dans son dossier d'installation, pas besoin d'aller placer des DLL ailleurs. * Pas de base des registres (enfin presque), le choix du "tout fichier" est excellent. * Très bonne gestion des droits d'accès. * Excellente gestion du réseau. Inconvénients * Sa modularisation est son plus gros défaut : Chaque application doit pouvoir tourner sous différentes distributions, ce qui pénalise son expansion auprès des utilisateur néophytes. * Enfer des dépendances : Les dépendances aux bibliothèques selon les versions est un défaut énorme. Certaines applis ne tournent parfois que sous d'anciennes versions, ce qui oblige à downgrader son noyau... L'entretient du système demande un effort de rétrocompatibilité à l'ensemble de la communauté. * Il est incompatible avec les jeux (et qu'on ose se l'avouer ou pas, Wine reste une vieille daube pourrie qui fait très mal tourner les jeux, imparfaitement, lentement, et avec plein de bugs, et encore quand ils tournent. Même après 10 ans de développement). * Pas de centralisation du panneau de configuration, chaque panneau de conf devrait être accessible depuis un seul endroit. * Pas assez d'interfaces graphiques, personne ne devrait jamais avoir à bidouiller des fichiers de conf : Un truc m'énerve sous nux : Sous couvert d'un esprit communautaire, c'est en fait un énorme tas d'élitistes hypocrites qui se terre dans la communauté linuxienne, dans la mesure ou la moitié des programmes nécessitent la lecture d'une ReadMe de 30 Ko avant d'utiliser les progs en tapant des lignes de commandes. Puisque l'user a l'honneur d'utiliser linux, il doit se creuser la tête. Ce qui est intolérable. Les linuxiens ont trop tendance à estimer que l'user doit être capable de bidouiller, ce qui empêche la pénétration du système dans le grand publique. Que certains soient d'accords ou pas, la "ligne de commande pure et dure" est un concept archaïque et dépassé qui doit être abandonné si Linux veut progresser. Les programmes doivent être graphiques et intuitifs. Et certains ne l'ont toujours pas compris... Ce n'est pas à l'user d'aller à Linux, c'est à Linux de s'adapter à l'user. Bref, à force d'utiliser Windows et Linux (et UNIX, et Solaris, etc.), nous avons finit par être dégoûté des deux. Nous avons donc décidé de créer notre propre système d'exploitation qui sera un compromis entre les 2, il aura les avantages de Linux ET de Windows, et s'arrangera pour virer les défauts. Le directeur principal du projet est ingénieur en informatique, en réseau, et en électronique, avec un master de maths. Autrement dit, appelez-le Dieu parce qu'il code comme un Dieu. Qui plus est, il a ses entrées chez Microsoft, donc il connaît bien Windows et les (coûteuses) connaissances de ses spécifications (notamment celles requises pour créer des drivers). Quant à la motivation, elle évolue par accoups, c'est pour cela que le projet sera peut-être un vaporware... Tout dépend du temps que notre emploi-du-temps nous permettra d'y consacrer. En ce qui concerne le devenir, le projet sera bien entendu open-source et gratuit. Une double licence permettant aux entreprises de réutiliser le code est à l'étude... Si le projet mûrit, il sera sans doute confié à la communauté du libre. En espérant qu'ils seront capable de l'entretenir correctement, à cause de la complexité du code notamment, qui ne sera pas accessible à n'importe qui, même si nous allons essayer de détailler et commenter au maximum. Pour cela, un autre système de développement communautaire plus élaboré sera mis en place, avec des normes strictes. C'est pour cela que l'idée de développer notre propre langage de prog est né, mais là c'est un peu hard... A voir. Car le développement à la Linux : - "C'est bon, le code vous convient ?" - "Non, moi je trouve qu'il faudrait un P au lieu d'un p ici" donne un bordel monstrueux. Pour s'en rendre compte, il suffit de regarder le langage script Bash : J'ai rarement vu un bordel aussi énorme. C'est puissant, mais la clarté du langage relève d'une bande de trisomiques. Complètement illogique sur bien des points. Ce côté de Linux "bordel communautaire" est vraiment très agaçant. Les bases : Nous sommes conscient qu'il est impossible de réécrire un OS entier en partant de rien à 2. Nous devrons donc reprendre des briques de Linux telles que l'interface graphique (ext4, Compiz Fusion avec KDE parce que nous n'aimons pas Gnome, Firefox, Thunderbird, etc.), et il nous faudra sans doute y apporter notre contribution. Mais pour l'instant nous n'en sommes pas là. Nous en sommes en tout début. Au bases des bases. Après, nous reprendrons un maximum de composants afin de rendre le système le plus polyvalent possible. La programmation : La programmation des composants principaux sera faite en assembleur. Norme X86 standard et X64 (AMD64). La plupart des bouquins d'ASM sont actuellement trop vieux, et l'ASM a évolué depuis. Ce langage est notre point fort dans la mesure où nous le maîtrisons bien, ce qui est extrêmement rare parmi les informaticiens que ce langage fait fuir. Nous avons remarqué actuellement, les capacité des processeurs sont sous-exploitées par rapport à ce qu'elles pourraient être. Nous avons donc voulu remédier à cela. Cela devrait permettre d'accélérer le système d'un facteur allant entre 6 et 20. Donc très rapide (je ne sais pas si vous avez déjà fait de l'ASM mais en terme de perf, il n'existe rien de mieux (mais rien de pire à coder)). Les parties ne nécessitant pas d'ASM seront faîtes en C++. Le directeur du projet a émit l'idée de créer son propre langage de programmation pour le reste, mais nous ignorons si ce projet sera maintenu. Personnellement je ne pense pas... Le compromis : Le but de notre OS est de concilier les avantages de Linux et Windows. Le noyau : Pour l'instant, seul le boot est terminé. Ca marche, et ça marche bien, vu qu'en assembleur, les choses vont bien plus vite. Cette fois, quand on vous dit que l'ordinateur va s'allumer comme une TV, ce sera vrai. Pour la structure, nous avons opté pour une sorte de noyau hybride (dans le détail ce sera légèrement différent mais je ne ferai pas de technique sur ce topic). Pour faire simple : Un gros noyau qui gère le principal (notamment répartir les tâches entre les micro-noyaux) et d'autres noyaux à côté. Seul ce système nous permettra de concilier Linux et son monolithique modulaire, et Windows avec son nuage de services, le tout étant d'éviter au maximum le bordel de services de Windows, et le fait de devoir sans cesse recompiler son noyau sous Linux. La principale particularité du noyau résidera dans le fait que, pour parler simplement, le noyau s'arrangera pour que chaque programme utilise toutes les capacités du CPU. Le principe est identique à la compilation sur chaque machine proposée par feu-Gentoo. Très vulgairement : Le noyau utilisera un fichier pour chaque type de processeur, et sur ce fichier seront mentionnées les instructions spécifiques aux processeurs ainsi que la transcription des jeux d'instructions de base afin d'utiliser ces instructions spécifiques. C'est la tâche la plus complexe à mettre au point mais c'est en cours. Le plus difficile est de rendre les choses le plus limpide possible afin de permettre à d'autres de reprendre le travail. Nous sommes catégoriquement contre le système de noyau Linux, à savoir le système modulable. Le manque d'unicité de ce noyau, le fait qu'il faille réadapter à chaque fois les paquets pour chaque distribution, est un frein majeur à l'expansion de Linux. Nous pensons que s'il y avait UNE norme Linux et que toutes les applis Linux pouvaient tourner sur toutes les distribs, le système se développerait bien plus vite. Le fait de ne (pas toujours) pouvoir réutiliser des paquets Debian sous Ubuntu n'a aucun sens. Le but est donc de faire un noyau performant et unifié. Le noyau devra supporter des applications des 2 système nativement, Windows et Linux, c'est à dire sans émulation (pour Linux, seuls les paquets Debian et autres distribs majeures seront pris en charge). Sécurité et droits d'accès : Les comptes Administrateur et Utilisateur ne seront plus seuls. Il est prévu de tout pousser à l'extrême en faisant 4 ou 5 types de comptes : - Super-administrateur : Les droits seront supérieurs au "root" du linux actuel. C'est impossible me direz-vous, si vous répondrais-je, avec encore plus de commandes et des priorités totales, notamment sur le Hardware. Destruction de PC garantie pour les bidouilleurs. - Administrateur : Tous les droits mais des interdictions pour les risques de destruction logicielle / matérielle - Utilisateur : Compte normal. Interdiction d'installation / désinstallation. Le compte sécurisé. - Enfant : Compte Utilisateur paramétrable à souhait sur le contrôle parental, les applis autorisées... Au coeur du système dans la mesure où les enfants vont de plus en plus dans le cyber-world, et c'est pas toujours très bon. - Invité : Le compte minimal. Un passe pour l'admin sera demandé à l'installation. Le super-admin sera verrouillé par défaut et accessible que depuis l'admin. Après tout se fera depuis un compte utilisateur avec des élévations de droits requises. Le système Linux en somme. Certains applications pourront s'exécuter toujours en admin dès le démarrage, mais il faudra gérer ça de manière sûre. Centralisation et Sectorisation : Certains choses devraient être centralisées, et d'autre non. Les applications ne devraient JAMAIS être centralisées, car elles proviennent de plusieurs éditeurs différents. Microsoft a fait cette erreur cruciale, Linux ne l'a (presque) pas faite. Chaque application ne pourra donc s'installer que dans son dossier d'installation et pas ailleurs. Ou alors en ayant des droits de super-admin. Pas de composants placés ailleurs que dans le dossier d'installation. system32 sera le répertoire de Windows et rien de plus, pas de DLL supplémentaire venant de DivX ou Real... => Pour l'instant, nous hésitons entre le fait d'obliger à copier chaque bibliothèques dans chaque dossiers d'applications, ou le fait de faire un fichier de configuration (par exemple pour les .exe, permettant de référencer les versions des DLL nécessaires). Je pense que la première se fera, avec une possibilité copie automatique... Les disques durs se font de plus en plus gros, donc copier un grand nombre de fois la même bibliothèque n'est pas tellement un problème... Cela éviterait notamment les problèmes de rétro-compatibilité dus au vieillissement des applications qui ne supportent plus les nouvelles versions des bibliothèques... Typiquement les jeux qui utilisent de vieilles versions de Direct3D ou DirectDraw... Ici, chaque application pourra s'exécuter dans l'environnement de son époque en ayant dans son répertoire une copie du DirectX correspondant... A voir... La configuration DOIT être centralisée, car il n'y a qu'une seule configuration, un seul PC. Il faudra donc 1 menu de config avec des interface graphiques pour tout. Notamment afin d'éviter les conflits de raccourcis claviers, très chiants sous Linux... Pour ce qui est des systèmes d'interface graphique, il faudra collaborer avec l'équipe de KDE / compiz-fusion... A voir... La base des registres de Microsoft ne devrait pas être centralisée. Chaque clé de registre d'un programme devrait être dans un fichier genre .reg contenu dans le dossier de celui-ci. Un équivalent de gestion du registre est à l'étude pour Phoenix, car il faudra forcément gérer cette plaie. Drivers : Support des pilotes des 2 systèmes nativement, avec en priorité le support des pilotes graphiques Windows. Les pilotes Linux sont très faciles à créer, du fait de la limpidité des standards. Tant que l'on a les spécifications du matériel, tout fonctionne bien. Les pilotes windows sont très chiants à créer, et il faut payer cher pour avoir les normes. Mais ils sont incontournables, surtout au niveau graphique. Le fait est que Linux ne tourne correctement que sur du matériel standard. Il faudra donc remédier à cela. Le prise en charge devra être effectuée sur les micro-noyaux parallèles à cause de l'évolution des normes. Le support du plug and play, très mal géré sous linux, sera essentiel ici. Support du stockage de masse, des baladeurs mp3, et des téléphones portables. Inclusion de drivers propriétaires obligatoire donc. C'est un frein pour certains linuxiens, mais pas pour nous. Exécution sécurisée : Contre les viri, il faudrait un système permettant d'identifier nativement un virus de manière heuristique. Linux n'a pas le défaut des viri car les dépôts des packages sont bien protégés. Mais aller chercher des paquets ailleurs devient dangereux. L'exécution d'un exécutable devra donc conduire à son analyse, et une sorte d'UAC devra prévenir l'utilisateur en cas de réalisation de certaines opérations dangereuses (pas de fenêtre ouverte, écriture dans le système, etc.), le tout conduisant à un % de probabilité de virus et à un avertissement. Le tout étant de ne plus jamais avoir à utiliser d'anti-virus, de les rendre obsolètes, à moins qu'un type s'amuse à exécuter un virus en super-admin. Gestion du réseau : Celle de Linux sera conservée, bien meilleure. Il faudra faire quelques modules pour la compatibilité windows, mais rien de bien méchant. DirectX et émulation : La prise en charge des jeux vidéo est une nécessité aujourd'hui. C'est chiant à dire, mais Windows ne reste n°1 du marché qu'à cause de 60Mo de DLL. Il sera donc essentiel ici de prendre en charge directX, le support de toutes les versions jusqu'à la 11 devra être prévu sans devoir tout réécrire (en réutilisant les DLL de Microsoft). De même, l'émulation des consoles devra être une priorité, des vieilles consoles jusqu'à la PS2 et XBOX. C'est là que les micro-noyaux vont aider, notamment avec le support du noyau Windows. Il faudra s'arranger aussi pour articuler les applications graphiques comme KDE/Compiz et les jeux vidéos sans avoir de conflits (style désactiver l'un quand on lance l'autre...), système à l'étude, idées bienvenues. Cryptage : A l'heure où nous entrons dans les rêves d'Orwell avec des lois votées de plus en plus liberticides, il apparaît comme nécessité de créer des système sécurisés nativement. à la clé - Support du cryptage de dossier - Support du cryptage de disques durs - Support de plusieurs types de cryptages via des modules - Support des cryptages multiples (selon la clé que vous entrez au départ, seuls certains fichiers seront visibles ou pas, permettant de cacher une partie de son disque dur, en cas par exemple de confiscation du PC par les autorités) - Possibilité d'effacement d'un fichier par réécriture successive afin de le détruire complètement (les flics peuvent remonter jusqu'à 32 fois chaque clusters) Les problèmes juridiques : Nous avons décidé de nous passer des problèmes de licence. En effet, il existe des brevets sur le double-clique, sur le clique droit, sur la barre de progression... Il est évident qu'un système libre compatible DirectX fera hurler Microsoft. Nous avons décidé d'ignorer ce problème, estimant que les brevets étaient un inutile frein à l'innovation. Nous verrons en temps voulu... Où ça en est : Au début. Pour l'instant, ce projet reste un ensemble d'idées. Seules quelques milliers de lignes de codes ont été écrites, les prémices du noyau. Cela représente bien peu de choses, mais il est indispensable de savoir où nous voulons aller. Donc n'hésitez pas à balancer ce qui passe par la tête, tant que ça reste constructif. Je répète que ces idées devront concerner le bas-niveau, pour l'interface graphique et toutes ces fioritures, on en est pas encore là.
×
×
  • Créer...