Souvent, on dit que si M$ se fait beaucoup emmerder sur la vente liée, alors Linux aura des super parts de marché .
Personnellement, j'y crois pas, sauf si Linux utilise des méthodes monopolistes dont je ne douterais pas ("The Linux developers are selfish dickheads") .
On parle souvent de la mauvaise qualité de Windows (d'ailleurs quand va-t-il se faire dépasser par ReactOS ?), mais jamais des défauts de Linux . Je cache donc volontairement ses qualités .
1) Linux est dépassé .
Et depuis longtemps, puisque déjà en 1992 il était critiqué par Tanenbaum comme étant un gros noyau monolithique . Et de plus Linux n'a pas les couches de portabilité de NetBSD, ce qui fait que le code PCI doit en fait être réécrit à chaque pilote de carte PCI (IA32,IA64,SPARC,etc.), par exemple .
Référence : http://oreilly.com/catalog/opensources/book/appa.html
Et ça n'a pas changé pour la version 2.0, lorsque les modules sont apparus .
Le bon sens disait qu'il faudrait exécuter les modules dans l'espace utilisateur pour avoir une sécurité accrue en empêchant les pilotes de faire des conneries .
C'est surtout important dans le cas de pilotes expérimentaux ou de pilotes propriétaires, et ces 2 cas existent .
En faisant des modules s'exécutant en mode noyau, Linux 2.0 s'est tiré une balle dans le pied, sans aucun doute pour éviter de convertir les pilotes existants .
Résultat en 2008 : certains ont des affreux blobs de Atheros/ATI/Nvidia qui font ce qu'ils veulent de l'ordinateur .
2) Linux utilise abusivement le modèle du bazaar .
Je ne dis pas que le modèle du bazaar est mauvais, mais il manque une distribution de base officielle, une vraie distribution qui soit solide comme Debian ou Slackware . Ce serait comme la distribution officielle de FreeBSD, par exemple . Après, on peut faire comme DesktopBSD et faire des dérivés compatibles, mais AMHA il faut une distribution officielle de base pour que la majorité des distributions puissent être compatibles .
Debian et Slackware sont de bons candidats, mais il faut un avis des développeurs du noyau car sinon les distributions qui ambitionnent d'être la référence se multiplient et du coup aucune distribution de référence n'existe .
3) ALSA est merdique .
D'abord, un problème qui se remarque vite, dmix ne supporte pas l'émulation OSS alors que même FreeBSD arrive à mixer correctement pour des applications OSS .
Ensuite, sur la page http://4front-tech.com/hannublog/?p=5, petite traduction de morceaux que j'ai choisis .
Par rapport à OSS :
-Basé sur le standard UNIX/POSIX des fichiers dans /dev
-Une API simple qui rend le travail des programmeurs plus facile
-Uniquement dans le noyau
-Mixage virtuel transparent rendant possible pour un nombre arbitraire de programmes l'usage de la même carte son, enregistrement inclus .
Par rapport à ALSA :
-Mal documenté .
-Peu d'abstraction du matériel
-Conçu pour une latence 0 dont peu d'applications ont besoin, ce qui rend difficile l'utilisation normale .
-Nécessite des bibiliothèques redondantes augmentant la consommation mémoire . Cela augmente la charge pour les systèmes embarqués .
-Méthodes de transfert multiples .
-Certains pilotes utilisent des canaux entrelacés, d'autres pas .
-L'API est basée sur des callbacks qui nécessitent une compétence de haut niveau de la part des programmeurs . Les gotos sont considérés comme mauvais depuis des décennies . Les callbacks sont encore pires .
Journal env TROLL=yes FRIDAY=yes echo Linux is defective by design
11
juil.
2008
# boulet
Posté par Octabrain . Évalué à 8.
En 92, Tanenbaum a dit que Linux c'est mal. C'était vraiment très intéressant.
2) Tu ne fais que dire "une base de distribution saimieux", mais je ne vois pas pourquoi. Et "pour que la majorité des distributions puissent être compatibles", c'est un peu générique et plat...
3) "[ALSA est] Conçu pour une latence 0", c'est clair que c'est vraiment un désavantage. OSS comme ALSA ont peu de fonctionnalités, dès qu'on veut quelque chose d'un peu puissant, il faut des bibliothèques.
"Les callbacks sont encore pires ."
boulet.
[^] # Re: boulet
Posté par left . Évalué à -5.
> boulet.
ou pas.
[^] # Re: boulet
Posté par FreeB5D . Évalué à -6.
man FreeBSD
man DesktopBSD
man PC-BSD
""Les callbacks sont encore pires ."
boulet."
C'est une traduction .
BOULET .
[^] # Re: boulet
Posté par Octabrain . Évalué à 3.
=> "No manual entry for FreeBSD"
T'as d'autres arguments plus explicites pour le neuneu que je suis ?
"C'est une traduction"
Tu le cites comme référence, et comme tu ne trouves rien à ajouter à ça, je suppose donc que tu es du même avis que lui.
# hourra !
Posté par Sébastien B. . Évalué à 9.
[^] # Re: hourra !
Posté par Snarky . Évalué à 9.
[^] # Re: hourra !
Posté par Pinaraf . Évalué à 3.
Et colinux, ils l'ont compilé comment ?
Puis y'a gcc sous windows, je suppose qu'une cross compilation est possible aussi dans ce sens là...
[^] # Re: hourra !
Posté par ThelittlegamerS . Évalué à 1.
Bien sûr, GCC n'est pas en cause. Maintenir un cross-compiler est une chose ardu, demandant énormément de travail généralement peu gratifiant, et le niveau d'usabilité de ceux-ci est déjà un exploit en soit.
[^] # Re: hourra !
Posté par libre Cuauhtémoc . Évalué à -2.
4- pas de thunes
5- pas de force commerciale
6- Pas de support editeur (pas de photoshop, pas de Quark Express, pas de Catia)
7- Pas de "finition" propre: le noyau est continuellement en developpement, ce qui laisse un avant goût d'inachevé
[^] # Re: hourra !
Posté par Sébastien B. . Évalué à 8.
4 - bah pas de tunes, ca servirait à quoi ?
5 - une force communautaire, c'est encore meilleur
6 - bah tu peux pas inclure photoshop, Quark Express ou Catia dans un noyau si tu es psychologiquement sain
7 - l'informatique évolue, donc le noyau aussi, logique non ?
# Et?
Posté par Zenitram (site web personnel) . Évalué à 4.
Tu remontes le temps à 1992, il y a 16 ans... Je constate qu'en 16 ans, ton OS adoré a avancé de... rien du tout. En tous cas beaucoup moins que le truc "pourri" qu'est Linux.
Si Linux a avancé 1000x plus que xBSD, c'est sans doute que Linux a certes des défauts, mais moins que ton OS adoré... Donc pourquoi ne pas parler des défaut de ton OS adoré? Genre l'incapacité chronique à avoir une seule distribution de référence (combien de branches xBSD pour combien de noyaux Linux officiels?), l'incapacité de faire des concessions pour avancer en attendant que tout le monde accepte le 100% libre (les drivers proprio, ça pue certes, mais au moins ça fait basculer des gens aux monde Linux...)
Bref, du bruit pour pas grand chose de neuf.
PS : je respecte autant les xBSD que Linux, c'est volontairement provocateur sur les xBSD juste pour une personne, désolé pour les autres (Je ne fais pas de jaloux, j'ai Windows encore à la maison, désolé :) )
[^] # Re: Et?
Posté par Obsidian . Évalué à 4.
Je sors.
[^] # Re: Et?
Posté par libre Cuauhtémoc . Évalué à -1.
[^] # Re: Et?
Posté par Kerro . Évalué à 7.
Es-tu au courant que beaucoup de choses circulent entre les BSD et Linux ? Que les uns et les autres sont d'excellents systèmes ? Et surtout avec des buts différents.
Tu prétends que Linux avance 1000 fois plus vite que les BSD. Il manque un lien pour étayer cette étonnante affirmation. Je n'ai pas encore vu Linux sur Amiga, sur Dreamcast, sur Sparc, sur VAX. Pourtant NetBSD fonctionne sur ces architectures. Je n'ai pas encore vu Linux sur les cartes embarquées traditionnelles dans les machines outils alors que NetBSD y réside depuis longtemps. Je n'ai pas vu non plus Linux étant aussi stable que NetBSD. Linux est très stable, mais mon expérience personnelle m'a montré que NetBSD l'est bien plus: je n'ai jamais vu son noyau planter. Ja-mais. Je gérais pourtant 14 machines allumées 24h sur 24 sous NetBSD.
Tu prétends que les BSD n'ont pas de distribution de référence. Ah tient, il y a en 3 qui sont "très" principales. Le noyau Linux lui a un code source de référence, mais peu de distribution l'utilise tel quel, d'où beaucoup de "références" pour la configuration et les correctifs (une chez Debian, une chez Ubuntu, une chez Red-Hat, et chez Suze, une chez machin, ...).
Tu prétends que les BSD sont dans l'incapacité de faire des concessions sur le libre. C'est un défaut ? Les chieurs d'OpenBSD par exemple arrivent parfois (souvent?) à faire mieux que les autres pour ouvrir les spécifications de certains matériels, tu trouves que c'est un défaut ? Les chieurs de NetBSD n'aiment pas du tout les blob entre autres parceque ça empêche de compiler sur des architectures étranges, tu trouves que c'est un défaut ?
Ton PS indique que tu gesticules beaucoup alors que tu utilises Windows chez toi. Tu n'utilises donc pas Linux "en vrai à la maison".
[^] # Re: Et?
Posté par Zenitram (site web personnel) . Évalué à 3.
Sinon, je vais quand même réagir à certains propos :
Ah tient, il y a en 3 qui sont "très" principales.
3, c'est 2 de plus que Linux
Le noyau Linux lui a un code source de référence, mais peu de distribution l'utilise tel quel, d'où beaucoup de "références" pour la configuration et les correctifs
De mon point de vue, ça montre que Linux est 1000x plus utilisé que les xBSD : d'autres entreprises "jouent" avec le noyau Linux pour l'adapter à leurs besoins spécifiques, alors que pour les xBSD on installe et on met des trucs à coté. Je ne crois pas que les xBSD répondent aux millions de besoins spécifiques, juste que c'est moins développé et que ceux qui ont des besoins spécifiques prennent un truc qui leur convient mieux.
je n'ai pas encore vu Linux sur Amiga, sur (...)
Je n'ai pas encore vu de xBSD dans le top 500 des machines les plus puissantes, elles sont toutes spécifiques, ça en fait des architectures...
Bref, tu donnes des exemples, il y en a d'autres pour Linux. Et je préfère un OS qui tourne sur des choses utiles que des proof of concept.
Les chieurs de NetBSD n'aiment pas du tout les blob entre autres parceque ça empêche de compiler sur des architectures étranges, tu trouves que c'est un défaut ?
Si ils refusent les BLOBS distribuables qui ne s'exécutent que sur le matériel précis, oui c'est un défaut, car ça n'empêche pas la chose de compiler sur x architectures différentes.
Ton PS indique que tu gesticules beaucoup alors que tu utilises Windows chez toi. Tu n'utilises donc pas Linux "en vrai à la maison".
Et alors, il faut être "utilisateur" pour critiquer? Impossible de discuter avec des utilisateurs de Linux ou de xBSD parce que je suis encore sous Windows à la maison? Désolé, j'ai horreur du racisme, et être anti-Windows est comme être raciste : je suis différent de toi, et alors? Ca ne m'empêche pas de pouvoir argumenter. Ta phrase est donc très mal venue, car elle n'a rien à faire dans le texte. Désolé, mais non, je ne pense pas que Windows c'est le mal absolu, vivre en communauté, c'est vivre tous ensemble, qu'on soit pro xBSD, Linux, Windows, ou Mac, dans que l'un respecte tous les autres, et je me répète, j'ai critiqué les xBSD juste pour remettre à leur place les anti-Linux pro-BSD, je ne suis pas un seul instant anti-BSD. Juste que les pro-BSD m'insupportent autant que les pro-Linux quand ceux-ci voient en leur OS fétiche le seul OS bon au monde.
[^] # Re: Et?
Posté par Octabrain . Évalué à 2.
[^] # Re: Et?
Posté par suJeSelS . Évalué à 10.
Regarde mieux alors. En ce moment je suis même entrain de mouler sur linuxfr avec un système ayant un noyau Linux sur... un UltraSparc (supporte officiellement aussi Sparc).
Pour tes autres exemples, il y fonctionne également. Il n'y a pas nécessairement de distribution proposant des binaires tout prêts, mais il fonctionne sur ces différentes machines/architectures.
[^] # Re: Et?
Posté par Thibault (site web personnel) . Évalué à 7.
Linux sur dreamcast : http://www.linuxdevices.com/articles/AT7466555948.html
Ensuite : http://www.linux-m68k.org/
Current releases of the m68k kernel are stable on the Amiga, Atari, many Apple Macintosh models, and several VMEbus single-board computers from BVM, Motorola and Tadpole. In addition, ports are underway (with varying levels of progress) to the HP 9000/300 series, the NeXT workstation (black hardware), the Q40 and Q60, and Sun 3 series workstations.
Linux sur sparc ? : http://www.linux.com/base/ldp/howto/SPARC-HOWTO.html
Linux sur VAX ? : http://linux-vax.sourceforge.net/
On peut même voir sur la page NetBSD de wikipedia :
NetBSD has been ported to a large number of 32- and 64-bit architectures [...] Although the Linux 2.6 kernel includes support for more processor architectures [...].
Réference : http://en.wikipedia.org/wiki/NetBSD et http://www.kroah.com/log/linux/ols_2006_keynote.html
[^] # Re: Et?
Posté par vjm . Évalué à 3.
Et oui c'est surtout ça qui est difficile, faire fonctionner l'OS complet pas juste faire booter le kernel (parfois en single-user seulement).
C'est aussi pour ça que FreeBSD divise ses plate-formes supportées en tiers : http://www.freebsd.org/doc/en/articles/committers-guide/arch(...)
Par exemple, il y a des développeurs qui bootent en multi-users sur du PowerPC ou du SPARC, mais ce ne sont pas pour autant des plate-formes Tier 1.
[^] # Re: Et?
Posté par benoar . Évalué à 4.
[^] # Re: Et?
Posté par Kerro . Évalué à 3.
C'est vrai que celles dont un constructeur à sorti deux modèles de bécanes, ce n'est pas évident de porter un OS dessus vu la disponibilité du matosC'est clair que dans certains cas il est théoriquement possible de le faire, mais personne de compétent n'a le matériel sous la main :-) Il suffit de voir la liste des matériels désirés chez NetBSD pour s'appercevoir qu'on n'en connaît même pas le dizième.
Cela dit, NetBSD à été porté sur x64 avant la disponibilité des processeurs, tout comme Linux, et probablement d'autres.
[^] # Re: Et?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est bien dommage. Linux tourne sur toutes ses architectures. D'ailleurs, cela fait quelques temps déjà que Linux tourne sur plus de chose que netBSD.
"La première sécurité est la liberté"
[^] # Re: Et?
Posté par Miod in the middle . Évalué à 2.
# Le son sous linux
Posté par Vlobulle . Évalué à 3.
À chaque fois que je tente de comprendre comment ça marche, je tombe soit sur des pages antédiluviennes (qui parlent d'OSS au présent, et d'ALSA au futur), ou alors des trolls bien poilus (qui parlent d'ALSA au présent, et d'OSS au futur, tel le lien du journal). Si à ça on rajoute les mixeurs qui changent selon le numéro de version distrib, j'en perds le peu de latin qui me restait.
En pratique, j'ai un chipset audio pourri (un realtek), j'utilise en permanence le son sous Wine (et ce jusqu'à ce que ventrilo et foobar soient portés), j'ai envie de régler le son aussi bien de manière indépendante pour chaque application que de manière globale (pas d'enceintes).
Y'a une solution viable (et pérenne) ? Ou je suis condamné à utiliser toutes les barres de volumes que je croise en espérant arriver à un compromis acceptable (ce que je fais actuellement).
[^] # Re: Le son sous linux
Posté par freeze . Évalué à 5.
[^] # Re: Le son sous linux
Posté par Snarky . Évalué à 2.
J'ai longtemps galéré avec le son sous Linux, mais depuis que j'utilise pulseaudio, j'ai beaucoup moins de soucis. Je peux régler mon volume pour chaque application, le mixage de faire très bien. Et, étonnamment, c'est déjà supporté par pas mal d'applications, malgré sa jeunesse.
[^] # Re: Le son sous linux
Posté par benja . Évalué à 6.
Disons que la sortie pulseaudio d'alsa aide pour beaucoup.
[^] # Re: Le son sous linux
Posté par peikk0 . Évalué à 2.
[^] # Re: Le son sous linux
Posté par benja . Évalué à 7.
-linux est critiqués pour être monolithique, avec les pilotes en espace noyau
vs.
-l'avantage d'ossv4 c'est d'être uniquement dans le noyau.
On pourra remarquer que tout le post du developpeur d'oss pue la mauvaise fois, comme le souligne justement ce commentaire: http://4front-tech.com/hannublog/?p=5,#comment-422 .
[^] # Re: Le son sous linux
Posté par benja . Évalué à 3.
[^] # Re: Le son sous linux
Posté par abramov_MS . Évalué à 7.
J'aime bien les "troll" de ce style, l'historique est generalement bien oublies. De meme du pourquoi Linux et pas xBSD ce n'est pas a cause ou grace aux qualites intrinseque de linux mais a cause du proces Berkley/AT&T qui a bloque xBSD pendant des annees pour des risques legaux. BSD c'est tres bien, c'est tres beau, c'est un Unix mais bon sa non adoption ou plutot la domination de Linux dans les OS libres est une question historique et non technique!
# Bien essayé :)
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 7.
1) Désolé mais quand on lit [0], on a vraiment pas l'impression qu'il faut écrire la totalité du code PCI pour faire un driver. D'ailleurs ce serait la folie, au vu du nombre de driver PCI dans le Kernel, tu imagine la redondance énorme, la taille du code, les bogues potentiels et le volume que ça générerai.
2) Effectivement on a pas de distribution référence, mais à quoi ça servirai concrètement ? tu as des standards, bon ou mauvais, comme la LSB. Fin bon, tu cite un fait sans dire ce que ça pourrais apporter selon toi. Ce qui serait intéressant c'est de savoir ce que cette distribution pourrait apporter au monde existant. Des standards, on en a déjà et des distributions utilisée pour être certifiée avec du matos pro aussi (genre SLES/RHEL), alors je vois pas à quoi ça servirai.
3) J'y connais rien dans ce domaine (tout du moins, pour mes besoins, ALSA est très bien).
[0] http://www.mjmwired.net/kernel/Documentation/pci.txt
[^] # Re: Bien essayé :)
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
> certifiée avec du matos pro aussi (genre SLES/RHEL), alors je vois pas
> à quoi ça servirai.
C'est clair. On a en pratique trois standard de fait aujourd'hui : RHEL et SLES et à un degré moindre la debian qui si elle n'est pas officiellement supporté, à une base utilisateur qui doit obliger les constructeurs a en tenir un tant soit peu compte.
Vouloir imposer un standard, c'est vouloir donner le monopole soit à Red-Hat, soit à Novell. Non merci.
Je préfère l'approche LSB qui n'impose rien à l'utilisateur et qui ne l'installe que s'il en a l'envie.
# ...
Posté par M . Évalué à 5.
-Mal documenté .
C'est pas faut...
-Nécessite des bibiliothèques redondantes augmentant la consommation mémoire . Cela augmente la charge pour les systèmes embarqués .
Pour la conso mémoire tu utilise la bibliothèque salsa. Pour la charge, la bibliothèque ne fait pas grand chose
-Peu d'abstraction du matériel
-Conçu pour une latence 0 dont peu d'applications ont besoin, ce qui rend difficile l'utilisation normale .
-Méthodes de transfert multiples .
-Certains pilotes utilisent des canaux entrelacés, d'autres pas .
Et ben tu choisis celle qui te plait ou tu utilises un code qui te l'abstrait. Au point précédent tu étais à cheval sur la conso cpu et memoire et maintenant, tu voudrais qu'ALSA fasse des choses dans ton dos...
-L'API est basée sur des callbacks qui nécessitent une compétence de haut niveau de la part des programmeurs . Les gotos sont considérés comme mauvais depuis des décennies . Les callbacks sont encore pires .
Heu tu connais pas tres bien alsa. L'API callback d'alsa est malheureusement très limité...
Sinon je te conseil de regardé comment fonctionne asio, portaudio, jack ... c'est que des callbacks...
PS : la prochaine fois avant de troller documente toi un peu
# Comprends pas...
Posté par xavier dumont . Évalué à 7.
Peux tu expliquer en quoi Debian n'existe pas ?
[^] # Re: Comprends pas...
Posté par superna (site web personnel) . Évalué à 1.
- Debian GNU/NetBSD http://www.debian.org/ports/netbsd/
- Debian GNU/kFreeBSD http://www.debian.org/ports/kfreebsd-gnu/
Argument 0 au niveau des distributions....
# Noyau Monolitique ?
Posté par superna (site web personnel) . Évalué à 8.
http://fr.wikipedia.org/wiki/Noyau_de_syst%C3%A8me_d'exploit(...)
Au premier abord, c'est très discutable aucun des deux n'est "meilleur" chacun a des énormes défauts...
Ensuite pour reprendre ton argument : Le noyau Linux était déjà qualifié d’obsolète par Andrew Tanenbaum[6], dès sa création en 1991. Il ne croyait pas, à l’époque, pouvoir faire un noyau monolithique multiplate-forme et modulaire.
Donc il s'est planté... fin de la discussion.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.