Ça ne sera plus vrai quand le Hurd sera pleinement opérationnel, d' ici quelques mois.
Le problème est que c'est codé à Arles.
A+ JF
Toxico Nimbus
JKB a écrit :
Explique-moi la pertinence des critères dans le choix de la cible de Linux. Pour moi c'est un SE qui peut tout faire, du Desktop (bureautique professionnelle ou informatique "familiale") à des solutions plutôt back office (serveur) et aussi de l'embarqué. Je ne vois pas d'autre SE qui s'adresse à une plage aussi large de la population.
Justement, c'est un problème. Plus on embrasse large, plus le truc doit faire des consensus et on arrive au schéma de développement des noyaux 2.6, c'est-à-dire à une catastrophe sous le simple prétexte d'inclure des pilotes trop frais, des fonctions pas vraiment testées et j'en passe.
Je ne vois pas le rapport entre la "largeur" de la cible et le modèle de développement du noyau. Pour moi, un modèle correct, c'est une branche par nouvelle /feature/, que l'on intègre quand elle est stable. Si les devs noyau ne sont pas capables de respecter cela, c'est qu'il ont un grave problème d'organisation.
> Les derniers noyaux sont orientés 'desktop'
Qu'est-ce qu'un noyau orienté desktop ?
> et il
faut patcher à mort pour obtenir un noyau utilisable sur du serveur (ne serait-ce que pour avoir du iSCSI target et initiator ou un système réellement stable). Je passe sur le fait que des bugs critiques de la VM n'aient pas été corrigé entre le 2.6.16 et le 2.6.30 sur amd64 (plantages aléatoires en fonction de la montée en charge), ce qui fait vraiment désordre pour des serveurs.
Je suis d'accord, mais comme je ne suis pas développeur noyau, ce n'est pas moi qui irai leur donner des leçons.
JKB a écrit :
Explique-moi la pertinence des critères dans le choix de la cible de
Linux. Pour moi c'est un SE qui peut tout faire, du Desktop (bureautique
professionnelle ou informatique "familiale") à des solutions plutôt back
office (serveur) et aussi de l'embarqué. Je ne vois pas d'autre SE qui
s'adresse à une plage aussi large de la population.
Justement, c'est un problème. Plus on embrasse large, plus le truc
doit faire des consensus et on arrive au schéma de développement des
noyaux 2.6, c'est-à-dire à une catastrophe sous le simple prétexte
d'inclure des pilotes trop frais, des fonctions pas vraiment testées
et j'en passe.
Je ne vois pas le rapport entre la "largeur" de la cible et le modèle de
développement du noyau. Pour moi, un modèle correct, c'est une branche
par nouvelle /feature/, que l'on intègre quand elle est stable. Si les
devs noyau ne sont pas capables de respecter cela, c'est qu'il ont un
grave problème d'organisation.
> Les derniers noyaux sont orientés 'desktop'
Qu'est-ce qu'un noyau orienté desktop ?
> et il
faut patcher à mort pour obtenir un noyau utilisable sur du serveur
(ne serait-ce que pour avoir du iSCSI target et initiator ou un
système réellement stable). Je passe sur le fait que des bugs
critiques de la VM n'aient pas été corrigé entre le 2.6.16 et le
2.6.30 sur amd64 (plantages aléatoires en fonction de la montée en
charge), ce qui fait vraiment désordre pour des serveurs.
Je suis d'accord, mais comme je ne suis pas développeur noyau, ce n'est
pas moi qui irai leur donner des leçons.
Explique-moi la pertinence des critères dans le choix de la cible de Linux. Pour moi c'est un SE qui peut tout faire, du Desktop (bureautique professionnelle ou informatique "familiale") à des solutions plutôt back office (serveur) et aussi de l'embarqué. Je ne vois pas d'autre SE qui s'adresse à une plage aussi large de la population.
Justement, c'est un problème. Plus on embrasse large, plus le truc doit faire des consensus et on arrive au schéma de développement des noyaux 2.6, c'est-à-dire à une catastrophe sous le simple prétexte d'inclure des pilotes trop frais, des fonctions pas vraiment testées et j'en passe.
Je ne vois pas le rapport entre la "largeur" de la cible et le modèle de développement du noyau. Pour moi, un modèle correct, c'est une branche par nouvelle /feature/, que l'on intègre quand elle est stable. Si les devs noyau ne sont pas capables de respecter cela, c'est qu'il ont un grave problème d'organisation.
> Les derniers noyaux sont orientés 'desktop'
Qu'est-ce qu'un noyau orienté desktop ?
> et il
faut patcher à mort pour obtenir un noyau utilisable sur du serveur (ne serait-ce que pour avoir du iSCSI target et initiator ou un système réellement stable). Je passe sur le fait que des bugs critiques de la VM n'aient pas été corrigé entre le 2.6.16 et le 2.6.30 sur amd64 (plantages aléatoires en fonction de la montée en charge), ce qui fait vraiment désordre pour des serveurs.
Je suis d'accord, mais comme je ne suis pas développeur noyau, ce n'est pas moi qui irai leur donner des leçons.
JKB
Le 16-10-2009, ? propos de Re: (bad) Trip Linux, Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Explique-moi la pertinence des critères dans le choix de la cible de Linux. Pour moi c'est un SE qui peut tout faire, du Desktop (bureautique professionnelle ou informatique "familiale") à des solutions plutôt back office (serveur) et aussi de l'embarqué. Je ne vois pas d'autre SE qui s'adresse à une plage aussi large de la population.
Justement, c'est un problème. Plus on embrasse large, plus le truc doit faire des consensus et on arrive au schéma de développement des noyaux 2.6, c'est-à-dire à une catastrophe sous le simple prétexte d'inclure des pilotes trop frais, des fonctions pas vraiment testées et j'en passe.
Je ne vois pas le rapport entre la "largeur" de la cible et le modèle de développement du noyau. Pour moi, un modèle correct, c'est une branche par nouvelle /feature/, que l'on intègre quand elle est stable. Si les devs noyau ne sont pas capables de respecter cela, c'est qu'il ont un grave problème d'organisation.
Si tu orientes le système vers le 'desktop', tu vas devoir rajouter des tas de choses comme le support du wifi, les framebuffer exotiques, l'USB et j'en passe. Et surtout, tu vas devoir proposer très rapidement les nouveaux supports et ce à chaque fois qu'un nouveau produit sort.
> Les derniers noyaux sont orientés 'desktop'
Qu'est-ce qu'un noyau orienté desktop ?
Un truc qui contiendrait un code pour un adaptateur FCAL _fonctionnel_ en lieu et place d'un support WIFI dont tu n'as que faire sur un serveur. Un truc qui contiendrait ce qui est utile sans bricolages abscons.
> et il
faut patcher à mort pour obtenir un noyau utilisable sur du serveur (ne serait-ce que pour avoir du iSCSI target et initiator ou un système réellement stable). Je passe sur le fait que des bugs critiques de la VM n'aient pas été corrigé entre le 2.6.16 et le 2.6.30 sur amd64 (plantages aléatoires en fonction de la montée en charge), ce qui fait vraiment désordre pour des serveurs.
Je suis d'accord, mais comme je ne suis pas développeur noyau, ce n'est pas moi qui irai leur donner des leçons.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 16-10-2009, ? propos de
Re: (bad) Trip Linux,
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Explique-moi la pertinence des critères dans le choix de la cible de
Linux. Pour moi c'est un SE qui peut tout faire, du Desktop (bureautique
professionnelle ou informatique "familiale") à des solutions plutôt back
office (serveur) et aussi de l'embarqué. Je ne vois pas d'autre SE qui
s'adresse à une plage aussi large de la population.
Justement, c'est un problème. Plus on embrasse large, plus le truc
doit faire des consensus et on arrive au schéma de développement des
noyaux 2.6, c'est-à-dire à une catastrophe sous le simple prétexte
d'inclure des pilotes trop frais, des fonctions pas vraiment testées
et j'en passe.
Je ne vois pas le rapport entre la "largeur" de la cible et le modèle de
développement du noyau. Pour moi, un modèle correct, c'est une branche
par nouvelle /feature/, que l'on intègre quand elle est stable. Si les
devs noyau ne sont pas capables de respecter cela, c'est qu'il ont un
grave problème d'organisation.
Si tu orientes le système vers le 'desktop', tu vas devoir rajouter
des tas de choses comme le support du wifi, les framebuffer
exotiques, l'USB et j'en passe. Et surtout, tu vas devoir proposer
très rapidement les nouveaux supports et ce à chaque fois qu'un
nouveau produit sort.
> Les derniers noyaux sont orientés 'desktop'
Qu'est-ce qu'un noyau orienté desktop ?
Un truc qui contiendrait un code pour un adaptateur FCAL
_fonctionnel_ en lieu et place d'un support WIFI dont tu n'as que
faire sur un serveur. Un truc qui contiendrait ce qui est utile sans
bricolages abscons.
> et il
faut patcher à mort pour obtenir un noyau utilisable sur du serveur
(ne serait-ce que pour avoir du iSCSI target et initiator ou un
système réellement stable). Je passe sur le fait que des bugs
critiques de la VM n'aient pas été corrigé entre le 2.6.16 et le
2.6.30 sur amd64 (plantages aléatoires en fonction de la montée en
charge), ce qui fait vraiment désordre pour des serveurs.
Je suis d'accord, mais comme je ne suis pas développeur noyau, ce n'est
pas moi qui irai leur donner des leçons.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 16-10-2009, ? propos de Re: (bad) Trip Linux, Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Explique-moi la pertinence des critères dans le choix de la cible de Linux. Pour moi c'est un SE qui peut tout faire, du Desktop (bureautique professionnelle ou informatique "familiale") à des solutions plutôt back office (serveur) et aussi de l'embarqué. Je ne vois pas d'autre SE qui s'adresse à une plage aussi large de la population.
Justement, c'est un problème. Plus on embrasse large, plus le truc doit faire des consensus et on arrive au schéma de développement des noyaux 2.6, c'est-à-dire à une catastrophe sous le simple prétexte d'inclure des pilotes trop frais, des fonctions pas vraiment testées et j'en passe.
Je ne vois pas le rapport entre la "largeur" de la cible et le modèle de développement du noyau. Pour moi, un modèle correct, c'est une branche par nouvelle /feature/, que l'on intègre quand elle est stable. Si les devs noyau ne sont pas capables de respecter cela, c'est qu'il ont un grave problème d'organisation.
Si tu orientes le système vers le 'desktop', tu vas devoir rajouter des tas de choses comme le support du wifi, les framebuffer exotiques, l'USB et j'en passe. Et surtout, tu vas devoir proposer très rapidement les nouveaux supports et ce à chaque fois qu'un nouveau produit sort.
> Les derniers noyaux sont orientés 'desktop'
Qu'est-ce qu'un noyau orienté desktop ?
Un truc qui contiendrait un code pour un adaptateur FCAL _fonctionnel_ en lieu et place d'un support WIFI dont tu n'as que faire sur un serveur. Un truc qui contiendrait ce qui est utile sans bricolages abscons.
> et il
faut patcher à mort pour obtenir un noyau utilisable sur du serveur (ne serait-ce que pour avoir du iSCSI target et initiator ou un système réellement stable). Je passe sur le fait que des bugs critiques de la VM n'aient pas été corrigé entre le 2.6.16 et le 2.6.30 sur amd64 (plantages aléatoires en fonction de la montée en charge), ce qui fait vraiment désordre pour des serveurs.
Je suis d'accord, mais comme je ne suis pas développeur noyau, ce n'est pas moi qui irai leur donner des leçons.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
doug713705
On Fri, 16 Oct 2009 12:53:21 +0200, olive wrote:
Pour tout le reste, le modèle
monolithique est mieux adapté parce que plus performant.
Ça ne sera plus vrai quand le Hurd sera pleinement opérationnel, d'ici quelques mois.
s/mois/jours/
-- Doug713705
On Fri, 16 Oct 2009 12:53:21 +0200, olive wrote:
Pour tout le reste, le modèle
monolithique est mieux adapté parce que plus performant.
Ça ne sera plus vrai quand le Hurd sera pleinement opérationnel, d'ici
quelques mois.
C'est normal, tu ne peux pas lui virer son module son...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 16-10-2009, ? propos de
Re: (bad) Trip Linux,
Patrice Karatchentzeff ?crivait dans fr.comp.os.linux.debats :
C'est normal, tu ne peux pas lui virer son module son...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
C'est normal, tu ne peux pas lui virer son module son...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
totof01
On 16 oct, 13:19, punisher wrote:
Un vrai marché, la nature a horreur du vide... mouais. L'avantage du libre est qu'un société de service peut proposer des solutions gratos et se gavé sur les prestations rien d'autre.
Qu'est-ce qui est mieux ? Proposer des solutions gratos et se gaver sur les prestations ou proposer des solutions payantes et se gaver sur les prestations ? Parce que d'un côté comme de l'autre, la prestation tu n'y échappe pa s (essaie de monter une supervision basée sur HP-OV sans prestation et tu m'en diras des nouvelles).
On 16 oct, 13:19, punisher <dr-punis...@rambler.ru> wrote:
Un vrai marché, la nature a horreur du vide... mouais. L'avantage du
libre est qu'un société de service peut proposer des solutions gratos et
se gavé sur les prestations rien d'autre.
Qu'est-ce qui est mieux ? Proposer des solutions gratos et se gaver
sur les prestations ou proposer des solutions payantes et se gaver sur
les prestations ?
Parce que d'un côté comme de l'autre, la prestation tu n'y échappe pa s
(essaie de monter une supervision basée sur HP-OV sans prestation et
tu m'en diras des nouvelles).
Un vrai marché, la nature a horreur du vide... mouais. L'avantage du libre est qu'un société de service peut proposer des solutions gratos et se gavé sur les prestations rien d'autre.
Qu'est-ce qui est mieux ? Proposer des solutions gratos et se gaver sur les prestations ou proposer des solutions payantes et se gaver sur les prestations ? Parce que d'un côté comme de l'autre, la prestation tu n'y échappe pa s (essaie de monter une supervision basée sur HP-OV sans prestation et tu m'en diras des nouvelles).
Toxico Nimbus
olive a écrit :
Ça ne sera plus vrai quand le Hurd sera pleinement opérationnel, d'ici quelques mois.
N'importe quoi, d'ici à ce que hurd soit aussi performant qu'un noyau monolithique, les poules auront des dents. Hurd est basé sur Mach qui n'est pas un foudre de guerre.
olive a écrit :
Ça ne sera plus vrai quand le Hurd sera pleinement opérationnel, d'ici
quelques mois.
N'importe quoi, d'ici à ce que hurd soit aussi performant qu'un noyau
monolithique, les poules auront des dents. Hurd est basé sur Mach qui
n'est pas un foudre de guerre.
Ça ne sera plus vrai quand le Hurd sera pleinement opérationnel, d'ici quelques mois.
N'importe quoi, d'ici à ce que hurd soit aussi performant qu'un noyau monolithique, les poules auront des dents. Hurd est basé sur Mach qui n'est pas un foudre de guerre.
JKB
Le 16-10-2009, ? propos de Re: Linux existe t'il en 128 bits ?, Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
olive a écrit :
Ça ne sera plus vrai quand le Hurd sera pleinement opérationnel, d'ici quelques mois.
N'importe quoi, d'ici à ce que hurd soit aussi performant qu'un noyau monolithique, les poules auront des dents. Hurd est basé sur Mach qui n'est pas un foudre de guerre.
Sur L4. Faut être à jour... Et debian/hurd fonctionne pas mal du tout.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 16-10-2009, ? propos de
Re: Linux existe t'il en 128 bits ?,
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
olive a écrit :
Ça ne sera plus vrai quand le Hurd sera pleinement opérationnel, d'ici
quelques mois.
N'importe quoi, d'ici à ce que hurd soit aussi performant qu'un noyau
monolithique, les poules auront des dents. Hurd est basé sur Mach qui
n'est pas un foudre de guerre.
Sur L4. Faut être à jour... Et debian/hurd fonctionne pas mal du
tout.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 16-10-2009, ? propos de Re: Linux existe t'il en 128 bits ?, Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
olive a écrit :
Ça ne sera plus vrai quand le Hurd sera pleinement opérationnel, d'ici quelques mois.
N'importe quoi, d'ici à ce que hurd soit aussi performant qu'un noyau monolithique, les poules auront des dents. Hurd est basé sur Mach qui n'est pas un foudre de guerre.
Sur L4. Faut être à jour... Et debian/hurd fonctionne pas mal du tout.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
totof01
On 16 oct, 13:51, punisher wrote:
Toxico Nimbus a écrit :
> punisher wrote:
Je suis pas d'accord, il y a les intégristes, ceux prône le python et qui pensent que le reste c'est de la merde par exemple, ceux qui pensent que faire de modélisation se sert a rien si un sait développer... tou t ça quoi...
De toute façon Python, c'est de la merde c'est trop rigide. Ruby est bien meilleur.
Pour ma part et pour être honnete, je connais assez mal windows, et les GUI je trouve ça vraiment superflux, certainement est-ce une question d'habitude. Je trouve que les choses n'avancent pas comme elles le devrait compte tenu du nombre de developpeur,
Mais comment devraient-elles avancer ? J'entends toujours "ca n'avance pas", "ca n'avance pas comme ça le devrait", mais c'est quoi "comme ça le devrait" ?
chez *BSD , dans la team
de teo les choses ne se passent pas du tout pareil, les gens y sont humble et très constructif, de vrai choix et vrai problématique et surtout de vrai arguement face au solution voté.
Theo ... Je suppose que tu parles de Théo de Radt ... :) Tu sais de qui tu parles là ?
, mais il a quand même un manque d'applications sérieuses et robuste... .
Non ... Il manque juste des jeux ....
Un fork oui mais qui est ridicule finalement, le noyau linux reste le même ensuite le système de packages bas on a pas trop le choix finalement car en reécrire un c'est chiant... ça revient a réinvent é la roue, toujours pour dire moi je fais mieux regarde... on la vue dans le web avec les navigateurs et le moteur Gecko... mouais...
euh .... Tu parlais de BSD et de Theo de Radt tout à l'heure .... Connais-tu l'historique et le mode de dev. des divers BSD ?
On 16 oct, 13:51, punisher <dr-punis...@rambler.ru> wrote:
Toxico Nimbus a écrit :
> punisher wrote:
Je suis pas d'accord, il y a les intégristes, ceux prône le python et
qui pensent que le reste c'est de la merde par exemple, ceux qui pensent
que faire de modélisation se sert a rien si un sait développer... tou t
ça quoi...
De toute façon Python, c'est de la merde c'est trop rigide. Ruby est
bien meilleur.
Pour ma part et pour être honnete, je connais assez mal windows, et les
GUI je trouve ça vraiment superflux, certainement est-ce une question
d'habitude. Je trouve que les choses n'avancent pas comme elles le
devrait compte tenu du nombre de developpeur,
Mais comment devraient-elles avancer ? J'entends toujours "ca n'avance
pas", "ca n'avance pas comme ça le devrait", mais c'est quoi "comme ça
le devrait" ?
chez *BSD , dans la team
de teo les choses ne se passent pas du tout pareil, les gens y sont
humble et très constructif, de vrai choix et vrai problématique et
surtout de vrai arguement face au solution voté.
Theo ... Je suppose que tu parles de Théo de Radt ... :) Tu sais de
qui tu parles là ?
, mais il a quand même un manque d'applications sérieuses et
robuste... .
Non ... Il manque juste des jeux ....
Un fork oui mais qui est ridicule finalement, le noyau linux reste le
même ensuite le système de packages bas on a pas trop le choix
finalement car en reécrire un c'est chiant... ça revient a réinvent é la
roue, toujours pour dire moi je fais mieux regarde... on la vue dans le
web avec les navigateurs et le moteur Gecko... mouais...
euh .... Tu parlais de BSD et de Theo de Radt tout à l'heure ....
Connais-tu l'historique et le mode de dev. des divers BSD ?
Je suis pas d'accord, il y a les intégristes, ceux prône le python et qui pensent que le reste c'est de la merde par exemple, ceux qui pensent que faire de modélisation se sert a rien si un sait développer... tou t ça quoi...
De toute façon Python, c'est de la merde c'est trop rigide. Ruby est bien meilleur.
Pour ma part et pour être honnete, je connais assez mal windows, et les GUI je trouve ça vraiment superflux, certainement est-ce une question d'habitude. Je trouve que les choses n'avancent pas comme elles le devrait compte tenu du nombre de developpeur,
Mais comment devraient-elles avancer ? J'entends toujours "ca n'avance pas", "ca n'avance pas comme ça le devrait", mais c'est quoi "comme ça le devrait" ?
chez *BSD , dans la team
de teo les choses ne se passent pas du tout pareil, les gens y sont humble et très constructif, de vrai choix et vrai problématique et surtout de vrai arguement face au solution voté.
Theo ... Je suppose que tu parles de Théo de Radt ... :) Tu sais de qui tu parles là ?
, mais il a quand même un manque d'applications sérieuses et robuste... .
Non ... Il manque juste des jeux ....
Un fork oui mais qui est ridicule finalement, le noyau linux reste le même ensuite le système de packages bas on a pas trop le choix finalement car en reécrire un c'est chiant... ça revient a réinvent é la roue, toujours pour dire moi je fais mieux regarde... on la vue dans le web avec les navigateurs et le moteur Gecko... mouais...
euh .... Tu parlais de BSD et de Theo de Radt tout à l'heure .... Connais-tu l'historique et le mode de dev. des divers BSD ?
