Linux unified kernel (LUK)

Système d'exploitation Linux
1

Linux unified kernel (LUK) a pour but de porter les fonctions du noyau windows dans le noyau linux

On peut déjà faire marcher bon nombre de programme mais on a besoin de wine pour tout ce qui n’a pas été implanter ou pour les api windows (car LUK c’est uniquement un noyau, a vrai dire un module pour le noyau linux qui permet au programmes windows de marcher dessus nativement )

À terme ça va permettre de faire marcher des drivers windows (quand ils n’éxistent pas sur linux) et des programmes (LUK fournis le noyeau et wine les api windows) et tout ça en restant libre (wine et LUK sont des projets opensource).

Parce que si un jour on veux que Linux soit plus répandue ou juste pour jouer(et même à la limite pour certaines applications professionnelles) Linux doit être compatible avec les programmes Windows même si il n’en a pas de besoin pour des tâches usuelles.

Le jour ou LUK deviendra mature il pourrais bien être intégrer dans le noyau officiel (encore du bouleau à faire) et je cite que Linus s’est dit ouvert à l’inclusion de code ayant pour but d’implenter les fonctions du noyau windows dans le noyau linux ce qui pourrais donner un petit boom à linux car LUK se développerais beaucoup plus vite ( quand les programmes marcherons sans wine sauf pour les api ce qui est presque le cas peut sera t’il prêt).

Avec ça on pourrais détruire les stéréotypes du genre <<linux ça marche avec rien>> ce qui est déjà faux mais une idée répendu car personne connais les programemes qui fonctionnent sur linux sauf les utilisateurs de linux (à peine 1%.)

Donc l’utilisateur qui viens de windows verra que ça marche et donnera le temps à Linux de montrer ses qualités.

D’un autre côté tout le monde qui utilise Linux aurra plus de choix de logiciels, sera enfin capable de faire marcher certains trucs qui n’ont pas de driver pour Linux et pourra peut être utilisez Linux au travail ( si il utilise son portable.)

Les programmes qui fonctionneront sur LUK ne fonctionneront pas en root mais en user et ne pourront pas exploiter les failles que les malware windows utilisent car ces failles sont prores à windows (LUK et WINE implentent les fonctions de windows mais pas les failles) il faudra donc faire un virus conçu pour attaquer spécifiquement Linux par l’entremise de LUK et de WINE ( autant en faire un qui marche sur Linux natif bordel… c’est déjà plus simples et ça reste que les failles se corrigent vite car opensource)

Et on peut toujours dire non je ne veux pas de logiciel propriétaire et n’installer que des programmes libres (linux ou windows) ou simplement virer LUK et WINE si on n’en veut pas ce qui reste simple à faire (présentement ne simplement pas les installer tout cour.)

Pour moi c’est la seule façon d’un jour démocratiser Linux car ce que la majorité des gens comprennet c’est que ça marche ou ça marche pas et les programmes windows ne marchent pas sur Linux…

En entreprise ça permettrais de faire le même travail mais sur Linux sans payer trop cher…

Ce projet est chinois et ils ont commencer la section anglaise de leur site.

Le code source est écrit en anglais il me semble…

Ce projet à changer de nom pour Longene mais LUK ou Linux unified kernel est encore utilisé.

Voici une description de wikipédia (anglais seulement) : en.wikipedia.org…

Le site anglais: [www.longene.org]www.longene.org…](http://www.longene.org/en/)

sourceforge (projet longene) : sourceforge.net…

Le documents relatif écrits en chinois seront traduits en anglais, un forum anglais éxiste et le site est en cours de traduction (certaine partie le sont et d’autre non)

Projet développer avec l’aide de Insigma Co., Ltd ( il y a des développeur à temps pleins mais pas beaucoup et de l’aide est la bien venu.)
Edité le 14/02/2009 à 00:04

2

Il ne manque aucune fonction dans linux (on parle bien du noyau). La majorité des fonctions de windows d’une part sont implémentés sous windows en tant que bibliothèques, et d’autre part sous linux devraient et sont implémentées en tant que bibliothèque.

De plus les rares fonctions de compatibilité entre Linux et Windows nécessitant éventuellement une implémentation dans le noyau le sont avec comme unique objectif d’améliorer les performances (ce qui est particulièrement crucial pour la fonction de lecture des FS sans casse, si on ne veut pas tester systématiquement l’existance de doublons FICHIERS/fichiers), et non pour des problèmes de manque fonctionnel du noyau.

Bref, à l’exception de quelques fonctions à développer dans un unique objectif de performances, il faut tout faire en mode user. C’est ce que fait Wine. Mais quand je vois la dernière news de LUK sur source forge (port de la gestion de la base de registre Wine directement dans le noyau!) j’hallucine complètement.

L’exemple que tu donnes est typiques de fonctions du monde user : bibliothèques graphiques 3D pour les jeux.

Ce projet est globalement mal pensé, inutile et fait un doublon mal conceptualisé avec Wine.

Enfin si le but est de garder les pilotes natifs Windows sous linux, il sera nettement moins coûteux et dangereux de réécrire les drivers natifs sous Linux.

Pour conclure, je ne soutiendrai pas ce projet. Je soutiens par contre Wine, et je soutiens l’effort de Wine et de Codeweavers pour implémenter les quelques appels systèmes linux qui pourraient améliorer drastiquement les performances de Wine.

Quant à Insigma Co., Ltd, - soit ils sont des incompétent majeurs - soit ils ont réussi à avoir des subventions sur un fantasme - soit ils développement un projet très différent de celui présenté dans ton message. (Chose probable, notamment si ils ne développent que la partie driver, bien que sois réticent à cette approche qui suppose une généralisation de code propriétaire binaire dans le noyau) Edité le 14/02/2009 à 02:05
3

Déjà l’idée de mettre des drivers windows sur linux sa na rien de propre.
mais l’implémenter en plus directement dans le noyau, c’est vraiment chercher les coups de bâtons. je parle surtout niveau stabilité (regarde le ntfs le temps que sa mi pour l’intégrer)

Projet mal pensé inutile et qui fait doublon avec wine
ps: Oula “made in china” ^ ^)

4

Les programmes windows tournent en user, LUK fournis les fonctions du noyau windows et wine s’occupe des api et des dll.

Plus rapide et permets au driver windows de fonctionner.

Il reste qu’il y a des trucs qui ne marche pas sous linux ça reste une solution.

Ça reste opensource (wine et LUK sont opensource), on peut s’en servir ou ne pas s’en servir mais on est plus libre car on a un choix de plus!

LUK ne commence pas de zéro: ils ont comme référence le kernel de reactos, wine et NdisWrapper.

Ils ont bien sur du étudier le kernel windows un tant soi peut…

Mais bref ils ont intégrés des briques de d’autre projets et au niveau du projet en tant que tel il est déjà bien avancé à ce stade embryonnaire puisque que nombreux programmes marche ( tout ce que fait wine car le peu de fonction qu’il reste à implanter wine les fournies) car présentement wine est obligé d’être avec LUK au niveau kernel mais pas pour longtemps car le projet avance vite.

En labo ils ont déja presque tout terminer ce qui touche à l’intégration avec le système de fichier.

Bientôt ça devrais sortir.

EN PASSENT LE PROJET EST EN STADE ALPHA ET FONCTIONNE DÉJÀ BIEN…
Edité le 14/02/2009 à 05:52

5

En fait le seul truc que ça apporte, c’est de charger directement les formats exécutables Windows et de les linker sur wine sans passer explicitement par Wine ? Soit, mais ça n’apporte rien de transcendant par rapport à un Wine sauf qu’on pourra avoir MSWord.exe directement dans /usr/bin au lieu de l’installer dans ~/.wine/c/ …

Même si c’est plus élégant, le gros de la solution est Wine, et entre parenthèse c’est aussi sur Wine qu’il faut concentrer les efforts pour compléter les bibliothèques manquantes.

Si tu pouvais m’en dire plus tu m’éviterai un crise d’apoplexie à cause de ce que je crains de comprendre.

Après pour le support des pilotes je suis moyennement enthousiaste (idem ndiswrapper).

Bon en fait le fait de supporter les format binaires natif windows au niveau noyau est plutôt intéressant. Là ou je me pose des questions, c'est sur l'intégration avec tout le reste.
... et surtout pourquoi tout faire en mode user. Il y a des fonctions à mettre dans le mode kernel (le chargement des formats binaires Windows) mais le reste doit rester userland; Lorsque je vois qu'ils réimplementent au niveau noyau les thread pour être conforme à Windows, mieux vaut faire une bibliothèque de compatibilité en user, qui fait du passing sur les fonctions noyau POSIX.
6

Tout à fait d’accord avec ça. Ce n’est pas la priorité, même si l’implémentation de certaines fonctions peuvent améliorer la vitesse de Wine.