Aller plus loin
- L'article sur Globe Technology (16 clics)
Linux, "successeur logique de AIX", selon IBM
7
fév.
2003
Linux toujours plus proche de la domination mondiale! En effet, même si ce n'est pas pour demain, IBM considère Linux comme le successeur désigné de AIX. L'article sur Globe Technology nous annonce que le remplacement total n'aura pas lieu avant (au moins) 10 ans mais reste un point de vue intéressant sur l'avenir de IBM et linux.
# Re: Linux,
Posté par unsigned (site web personnel) . Évalué à 10.
[^] # Re: Linux,
Posté par Nuks . Évalué à 10.
"Un si bon joueur pour presque rien ? Oui, il aime le jeu"
merci encore une fois a IBM de faire des pub pour linux, et en plus elle sont bien faite
[^] # Re: Linux,
Posté par Fabimaru (site web personnel) . Évalué à 9.
Ce qui sonne le mieux a l'oreille des decideurs c'est le cout, pas la liberte. Ca IBM (enfin les charges de la comm) l'a bien compris
[^] # Re: Linux,
Posté par fld . Évalué à 10.
Celui qui prend contact au travail avec du linux peut se dire que ce qu'il croyait obscure (par manque de connaissance) ne l'est pas tant que çà et pourrait lui éviter de payer des logiciels toujours plus chers chez lui.
Du coup toute sa petite famille en profite, ses voisins peuvent être amenés à découvrir, les copains du bambin aussi ... : effet boule de neige !
Donc c'est cool même si à l'origine c'est une histoire de sous. Et je vois mal comment IBM pourrait arriver à un monopole sous linux comme microsoft avec windows : il y a ura toujours des possibilités pour la concurrence, toujours du GPL, toujours du gratuit et donc toujours accessible au plus grand nombre.
Et la je ne tiens même pas compte des apports qu'IBM peut fournir en code (pour le noyau par exemple), ni les outils de développement qu'il pourrait apporter (ni par exemple son staroffice comme le fait sun et là ce sera OOo qui sortira gagnant).
# Re: Linux, HURD
Posté par schyzomarijks . Évalué à 3.
[^] # Re: Linux, HURD
Posté par Tony Gencyl . Évalué à 4.
Biiiip tentative de troll detectee ...
<mode>
C'est possible, ca serait assez amusant.
Apres tout la particularite d'un OS c d'evoluer, non ?
Et puis ca ne signifie pas pour autant que tout le code qui a ete pondu dans pour le noyau Linux soit a jeter ...
Et puis ca nous ferait encore du boulot, au developpeurs, histoire de ne pas tous se voir delocalise en Inde ou en Chine
</mode rip_troll>
[^] # Re: Linux, HURD
Posté par gcherief . Évalué à 4.
On pourrait presque jetter le code du noyau linux :)
[^] # Re: Linux, HURD
Posté par Raphael Junqueira . Évalué à -5.
pcque moi j'en ai vu pas mal et la majorite tu leur confierait meme pas une appliquette (et malheureusement dans ma boite ils leur confient des parties assez critique :(( )
[^] # Re: Linux, HURD
Posté par wwp (site web personnel) . Évalué à 4.
J'ai pour ma part de nombreux collègues de travail (développeurs) indiens et suis en contact avec quelques un dans le cadre de projets open-source, et je crois remarquer qu'ils ne sont ni plus bêtes ni moins doués que les autres.
N'oublions pas que pas mal des ingénieurs IT en Inde se forment dans des écoles un peu partout dans le monde.
[^] # Re: Linux, HURD
Posté par Raphael Junqueira . Évalué à 0.
j'ai jamais dit que les devs europeens/americains codaient mieux, sinon Hurd ne serait pas dans l'etat dans lequel il est actuellement ;p
Maintenant je repondait a "l'allusion douteuse" qui sous-entendait que les si les "indiens" se "mettraient dessus" ca irait plus vite.
[^] # Re: Linux, HURD
Posté par Franck Yvonnet . Évalué à 10.
[^] # Re: Linux, HURD
Posté par jpph . Évalué à 2.
[^] # Re: Linux, HURD
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
http://www.urbanlegends.com/celebrities/bill.gates/gates_memory.htm(...)
[^] # Re: Linux, HURD
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à 3.
[^] # Re: Linux, HURD
Posté par Éric (site web personnel) . Évalué à 6.
(il est où ce -1 ?)
[^] # Re: Linux, HURD
Posté par notrya2 . Évalué à 3.
De tout manière, c'est souvent comme çà en free sofrware. Dès qu'un truc a beaucoup de succès, çà fait moins rebelle et on cherche autre chose.
# Re: Linux,
Posté par Dies Irae (site web personnel) . Évalué à 10.
Tout ce que j'espère c'est que ces sociétés comme IBM nous soutiendrons contre TCPA et autres actions "anti logiciel libre". Mais c'est pas gagné.
Pour HURD, quand il sortira :), je pense pas que l'un remplacera l'autre mais plutôt qu'ils auront tous les deux leurs place. Comme 99% des progs tourneront sur l'un ou l'autre, ça sera peut être plus un choix personnel. Enfin il reste à voir ce que ça donnera au niveau stabilité et performance par rapport à Linux. Mais des fonctionalités comme pouvoir monter un ftp distant en système de fichier local sont assez alléchante!
Pour revenir aux pubs IBM ils ont fait une page avec des anims flash bien marrant : je vous conseille surtout "free the code" :
http://www-1.ibm.com/servers/eserver/linux/fun/(...)
[^] # Re: Linux,
Posté par PLuG . Évalué à 7.
certes le bla bla habituel de micro noyau. mais dans la vie pratique les drivers ne plantent heureusement pas souvent sous linux, et pour leur developpement rien n'empeche d'utiliser user-mode-linux. Ton histoire de monter un serveur FTP en local existe deja sous linux (pas besoin de micro-noyau pour ca) ...
bref linux avec des modules c'est pas bien loin de notre futur HURD.
Pour moi le HURD c'est beau. mais ca n'apporte rien que linux ne peut faire.
[^] # Re: Linux,
Posté par gcherief . Évalué à 7.
[^] # Re: Linux,
Posté par Raphael Junqueira . Évalué à 7.
Maintenant pour les 100Mo, il faut etre realiste 99% des sources sont des drivers. Le kernel Linux en lui-meme ne doit pas faire plus de 5 mo.
[^] # Re: Linux,
Posté par fld . Évalué à 2.
[^] # Re: Linux,
Posté par Pierre Tramo . Évalué à 7.
Le support des modules dans le noyau linux n'en fait pas un micro-noyau.
Un des intérêt du Hurd est que la plupart des serveurs fonctionne dans l'espace utilisateur, si je me souviens bien.
[^] # Re: Linux,
Posté par Raphael Junqueira . Évalué à 1.
Maintenant les "serveurs" des micro-noyaux correspondent plutot a des gestionnaires de drivers que les drivers eux-meme et dans ce sens linux va dans le meme sens (on peut facilement imaginer separer une bonne partie de la gestion des drivers du context noyau)
[^] # Re: Linux,
Posté par Jerome Herman . Évalué à 10.
1- Un micro noyeau peut faire tout ce que fait un noyeau monolithique. Outre le fait que ca soit super chiant a coder (mais alors beaucoup) un micro noyeau n'a pas d'inconvennient.
2- Un micro noyeau agit pour les fonctions de base comme un noyeau (timing, semaphores, ressources etc..) par contre pour tout ce qui est drivers il est out. Ce qui veut dire non seulement que si un driver plante, vu que mon noyeau n'est pas plante je peux continuer a bosser, mais surtout que je peux choisir mes drivers a la volee en fonction de mes besoins, avec une granularite qui peut descendre jusqu'au thread.
En d'autre terme on peut tres bien imaginer une appli qui utilise un driver graphique pour 80% de ses fonctions mais qui fasse appel a un autre driver pour les operation OpenGL par exemple.
Bien sur on peut aussi imaginer un utilisateur root qui n'a pas les memes drivers de carte reseau que les autres (implementation de ETH0 par exemple).
De plus pour un systeme micro-noyeau un certains nombre de choses qui sont implementees par le kernel passe en drivers (Gestion memoire, filesystems etc..) toutes ces choses sont donc configurable et adaptable a un groupe, un utilisateur ou meme un processus.
Il est meme theoriquement de declarer un deuxieme micro noyeau comme driver et de se lancer a tire larigo dans du kernel hacking sans risquer une seule fois de planter sa machine. Ou de donner a chaque utilisateur un noyeau different.
Kha
[^] # Re: Linux,
Posté par let antibarbie = xp <- xp - 1 . Évalué à 2.
Cela dit, déjà que les "décideurs" ont encore du mal à miser sur du Linux, ca va pas être gagné pour les faire basculer au Hurd (et pareil pour un utilisateur lambda).
Maintenant par la suite on progressera en ajoutant un peu de standardisation (e.g. au niveau des drivers ?).. et des applications cross-platform ne feront pas de mal pour faire bouger tout ça.
------
"Messieurs, vous n'êtes pas des travailleurs sociaux! les citoyens attendent d'abord de vous que vous arrêtiez les délinquants. Les activités de prévention, ce n'est pas le rôle des policers." Nicolas Sarkozy. (police academy 5?)
[^] # Re: Linux,
Posté par vazco . Évalué à 1.
--
noyeau n. m. : élément dans lequel se produisent des noyades ?
[^] # Re: Linux,
Posté par Raphael Junqueira . Évalué à 2.
1- Un micro noyeau peut faire tout ce que fait un noyeau monolithique. Outre le fait que ca soit super chiant a coder (mais alors beaucoup) un micro noyeau n'a pas d'inconvennient.
archi faux, tout depend de comment est architecturer ton micro-noyau (sans le "e"). Par exemple, Hurd ne sera jamais capable, si il garde son architecture actuelle, capable d'avoir un scheduleur de thread/io digne de celui de Linux
2-...
Tres peu vendeur, la majorite de ce que tu dit la, peut etre dit sur certains "noyaux monolythiques" mis a part la separation de contexte entre les drivers et le noyau qui est le gros avantage des micro-noyau (permet une gestion plus fine des droits, des dependances)
Il est meme theoriquement de declarer un deuxieme micro noyeau comme driver et de se lancer a tire larigo dans du kernel hacking sans risquer une seule fois de planter sa machine. Ou de donner a chaque utilisateur un noyeau different.
UML
[^] # Re: Linux,
Posté par Jerome Herman . Évalué à 1.
Ben oui. Ca depend. Il est parfaitement possible de faire du multitache preemptif dans un micro-noyau, et de faire de la planification stochastique des taches (ie d'exploser les fonctionalites linux). Cela ne change rien a ce que je disais, a part le cote programation "baleze" une architecture micro-noyau n'a que des avantages. Si Hurd gere de facon un peu brute les threads, c'est lie a l'implementation et non au choix d'une techno micro-noyeau.
Tres peu vendeur, la majorite de ce que tu dit la, peut etre dit sur certains "noyaux monolythiques"
Le mot clef que je n'ai peut-etre pas mis en valeur c'est "simultane"
on peut par exemple imaginer 40 personnes loguees sur un serveur en session terminal avec chacune un noyeau different, et un systeme de fichiers different (bien que donnant sur le meme disque dur). C'est vrai que certains noyaux monolythiques se rapprochent de ces fonctionalites, mais c'est le plus souvent par des methodes d'emulation et non par un comportement natif, donc au prix de la perf. De plus une fois l'emulateur en place, il bloque les ressources, et de fait interdit le lancement d'un autre emulateur un parallele, alors qu'un micro-noyau peut gerer autant de driver differents pour un meme peripherique que son implementation et le hardware le lui permettent.
kha
[^] # Re: Linux,
Posté par patrick_g (site web personnel) . Évalué à 6.
moi aussi j'ai jamais trop compris la structure du hurd (faut dire aussi que je suis une moule en technique)......mais j'ai trouvé un lien pas mal qui explique en 3 ou 4 pages les vrais avantages du hurd sur les OS existants et surtout qui explique ça dans un langage qu'un newbie comme moi peut (a peu près) comprendre :
http://etud.epita.fr:8000/~vernie_m/yal/fr/hurd.html(...)
voili voila
[^] # Re: Linux,
Posté par Fabimaru (site web personnel) . Évalué à 2.
Ouh la, tu t'aventures sur un terrain glissant :-)
[^] # Re: Linux,
Posté par Raphael Junqueira . Évalué à 2.
moi aussi j'ai jamais trop compris la structure du hurd (faut dire aussi que je suis une moule en technique)......mais j'ai trouvé un lien pas mal qui explique en 3 ou 4 pages les vrais avantages du hurd sur les OS existants et surtout qui explique ça dans un langage qu'un newbie comme moi peut (a peu près) comprendre :
http://etud.epita.fr:8000/~vernie_m/yal/fr/hurd(...)
enfin, ce site explique pas trop les avantages de Hurd par rapport a Linux ou freeBSD par exemple (qui doivent etre deux des os monolythiques les plus avances a l'heure actuelle)
Je pense que les avantages les plus "connus" du Hurd: translator, etc ... sont en majorites disponibles sous linux dans des couches user (par exemple le principe de kio de kde est exactement le meme que les translators, mais uniquement dispo que via les api kde).
Maintenant, le gros avantage de Hurd et qui restera uniquement dispo pour des micro-noyaux de facon aussi fine est la gestion ultra-fine de la securite.
OpenBSD s'en rapproche avec sa securite a la granularite des appels systemes, maintenant au nivo du Hurd il peut aussi gerer la securite au nivo des appels internes au noyau, des changement de droits (sorte de "su") inter-calls
[^] # Re: Linux,
Posté par Fabimaru (site web personnel) . Évalué à 1.
[^] # Re: Linux,
Posté par PLuG . Évalué à 3.
Je savais que quelqu'un allait se dévouer pour nous refaire le coup des serveurs en user-space, etc ...
J'ai bien lu tout cela mais je ne crois pas que cette différence soit si importante que cela dans le sens ou les avantages en souplesse ne sont pas interdit sur un noyau monolitique non plus...
D'un autre coté je n'ai pas dit qu'il fallait arreter sur le champ de coder Hurd hein ! La diversité ca a évidement du bon, surtout quand c'est de la diversité en GPL ou les expériences peuvent profiter aux 2 OS ...
[^] # Re: Linux,
Posté par notrya2 . Évalué à 2.
C'est le boulot de programme/librairie en user mode. Comme le fait mc ou gnome-vfs. Quoiqu'il en soit, je ne vois pas pourquoi Linux ne pourrait pas faire çà.
[^] # Re: Linux,
Posté par Raphael Junqueira . Évalué à 2.
C'est le boulot de programme/librairie en user mode. Comme le fait mc ou gnome-vfs. Quoiqu'il en soit, je ne vois pas pourquoi Linux ne pourrait pas faire çà.
c clair, surtout que linux peut le faire via "kio ftp" dans kde :)
# AIX -> Linux... 10 ans... ouf
Posté par Quzqo . Évalué à 10.
Côté Linux, "on" a déjà pas mal de choses pour faire de l'ombre à ce "grand" *nix propriétaire...
+ une forte réactivité
+ un prix défiant toute concurrence ;o))
+ un choix logiciel de plus en plus étoffé... voire typé professionnel (pléthore de LL + http://linuxfr.org/2003/02/07/11271.html,(...) http://linuxfr.org/sections/Articles.html...(...))
+ multiplateforme :
désolé mais j'M bien Debian ;o)
+ une/des alternatives à Motif/CDE
+ ...
Mais il reste quelques points sur lequels la concurrence n'est pas encore d'actualité :
+ l'administration du système (SMIT, VSM, WebSM et commandes étendues)
+ l'intégration matérielle (bien que biaisée).
+ les architectures massivement parallèles (clusters RS6000)
+ la normalisation (arborescences, sécurité...)
+ la documentation centralisée et accessible http://publib.boulder.ibm.com/cgi-bin/ds_rslt(...)
Un gros morceau !
...
Il "nous" reste encore dix ans... Ouf ;o)
[^] # Re: AIX -> Linux... 10 ans... ouf
Posté par fld . Évalué à 6.
A quand une license IBM partiellement compatible GPL (cad GPL pour tout le monde sauf microsoft, Sun , ...). Ca existe peut être déjà ?
[^] # Re: AIX -> Linux... 10 ans... ouf
Posté par Pierre Tramo . Évalué à 3.
Ce ne serait pas GPL, ce ne serait pas libre, ce serait Mal (tm).
[^] # Re: AIX -> Linux... 10 ans... ouf
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: AIX -> Linux... 10 ans... ouf
Posté par fleny68 . Évalué à 2.
Dans woody il n'y en a que 10: http://www.debian.org/ports/(...)
La onzième n'est pas encore supportée. Pas de CD officiels avec tous les paquets pour woody.
Dans Debian il y a un travail sur 11. Ce qui signifie que sarge pourrait avoir
11 architectures, si la onzième est prête à temps.
Je crois qu'il y a eu une discussion sur le hurd. Debian/hurd-i386 n'est pas dans woody. Manquait le firewall, crois-je me rappeler.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.