GeneralZod a écrit 2316 commentaires

Je viens de faire l'essai sur un macbook équipé de Snow Leopard, le finder afficher 734Mo effectivement.
J'ai regardé ce que donnait ls, les version BSD (ls -lh) et GNU (gls -sh) me donnent le même résultat: 700Mo. Normalement, tu ne devrais pas avoir de souci pour la gravure, je n'en ai pas eu. :o)

$ ls -sh F12-Beta-x86_64-Live-KDE.iso
701M F12-Beta-x86_64-Live-KDE.iso


Il y a déjà eu des remontées à propos de la béta mais tu es le seul à évoquer ce problème. Si tu ne l'as pas fait, je te recommande vivement d'utiliser BitTorrent.

Probablement qu'ils feront l'effort de le porter pour la prochaine version (ce qui est très appréciable) mais qu'après, soit les mainteneurs de Vserver se sortent les doigts du cul, soit ça saute.
On va pas demander aux mainteneurs Debian de faire le boulot des mainteneurs upstream ou de bloquer la version du noyau indéfiniment.

La différence entre un microcode et un pilote, c'est que le premier est exécuté par le périphérique, le second par la kernel. Théoriquement, un microcode est sensé remplacer de la logique câblée pour des raisons de coûts mais également légales pour le WiFi notamment (des histoires de fréquences, étendue, puissance, etc ...)
Mais parfois, ils mettent des trucs en plus.

Réécrire un microcode, c'est possible (si tu as la doc), c'est ce qui a été fait pour les chipsets broadcom, Fedora l'a inclus récemment (disponible pour F-10/11 dans les mises à jour).
http://www.ing.unibs.it/openfwwf/

Oui et non, les applications multimédias et gourmande en calculs bénéficient du x86_64 à de multiples titres:
- jeu d'instruction commun revu à la hausse pour inclure SSE2, GCC4 gère assez bien la vectorisation du code.
- 2x de registres, c'est moins que les CPU RISC mais c'est appréciable quand on connait l'amplitude des temps d'accès selon les différents types de mémoires.
De plus, la limite de 2Go n'est pas pertinente :
- le noyau linux 32 bits peut adresser 4Go théoriquement, à cause du PCI hole, on est plus près des 3 Go.
- les extensions PAE, on peut aller jusqu'à 64Go. À ce rythme-là, on ne passera pas au x86_64 avant la généralisation des méga-barrettes de RAM de 16 ou 32Go.

À moins d'avoir une bonne raison d'avoir du x86 (un CPU antique comme l'Atom) ou des contraintes fortes sur le système (comme en embarqué), il n'y a quasiment aucun intérêt à garder du x86 sauf si on est un rétrograde qui a peur d'évoluer. x86 on desktops should die!
Là, c'est plus que la prochaine Fedora sort dans un mois et que lui faire tout réinstaller peut être pénible.

En installant une Fedora x86_64, la différence ne sera pas flagrante, même si les performances globales sont améliorés.
Quant aux paquets, c'est à peu près pareil, sachant qu'avec le multilib, tu peux faire cohabiter des programmes 32/64 bits sans problèmes. Aucun intérêt de nos jours à rester en 32bits, d'ailleurs le x86_64 c'est 1/3 de la base installé chez Fedora (les 2/3 c'est souvent par ignorance ou des vieux CPU, Atom inclus)
Sauf si vraiment tu n'as rien à faire, réinstalle ta Fedora sinon attends la prochaine version qui sort dans un mois pour le faire.

La réponse à la fameuse lettre ouverte de Darly.
http://catb.org/~esr/writings/mcbride2.html

Légalement c'est douteux, les licences CC constituent des contrats et l'adhésion à la SACEM ne suffit pas pour invalider ces accords pour les oeuvres diffusés auparavant quoiqu'ils puissent croire.
La SACEM c'est une société de droit privé qui a une mission d'intérêt public sous la tutelle du ministère de la culture, c'est pas eux qui font la loi.

Ce n'est probablement qu'une partie de la réponse, mais j'y vois plusieurs raisons:
- portabilité: c'est plus facile de porter un micro-noyau qu'un noyau monolithique, ça explique la bizarrerie I/O Kit pour le développement de pilotes. NeXTSTEP tournait sur 4 plateformes (x86, m68k, PA-RISC, SParc, les fat binaries existaient déjà à l'époque), comme le passage à Intel l'a démontré, Apple y tient beaucoup.
- compatibilité: l'intérêt de Mach, c'est la possibilité d'assumer des "identités", la couche BSD permet d'assumer une identité Posix, la couche classic permet d'assumer une identité MacOS, il y a même eu une rumeur qu'Apple aurait mis au point une couche de compatibilité Win32.
Ces deux concepts sont importants pour Apple qui en une décennie a connu deux grosses ruptures technologiques: MacOS -> MacOS X, PPC -> x86 (on pourrait rajouter 32 -> 64 bits) qui sont passés comme du beurre. Mach est une composante de ce succès technologique.

D'un autre côté, Mach est ancien, Mach a des performances toutes pourrites, les grosses transitions sont passées, pourquoi le garder ? L'historique (réécrire tout les pilotes, réécrire des gros morceaux comme le runtime obj-C qui est inclus dans XNU, etc ...), peut-être une crainte de se tirer une balle dans le pied. Si le noyau Apple repose sur celui de FreeBSD, ça facilitera la tâche pour les hackintosh (actuellement, les hackinstosh repose sur des noyaux XNU open-source bidouillés), Darwin reste confidentiel, FreeBSD l'est beaucoup moins.
Éventuellement, la crainte d'une nouvelle transition Mac OS XI ?Je vois mal Apple passer comme ça à un noyau monolithique classique, les ingénieurs d'Apple doivent s'arracher les cheveux pour trouver un remplaçant à XNU qui satisfasse tout les critères d'un Steve Jobs ultra-perfectionniste.

Apple était intéressé pour remplacer Mach par Xen mais plus de nouvelles depuis à ce sujet. Puis quitte à passer sur un noyau Unix-like classique, pourquoi pas passer à Linux, ce ne serait pas la première fois qu'Apple s'y intéresse. Après tout, MkLinux c'était eux déjà.

Techniquement non, XNU le noyau d'OS X est un noyau hybride composé d'un micro-noyau Mach et d'une couche de compatibilité BSD qui sert d'interface "utilisateur" et apporte quelques trucs sympathiques genre VFS, pile réseau etc...
Historiquement, la couche BSD a pris du code provenant de BSD 4.3 puis 4.4, puis les premières versions de développement d'OS X ont également tapé dans NetBSD puis finalement FreeBSD. Apple a embauché plusieurs gurus de FreeBSD dont l'un des co-fondateurs Jordan Hubbard et il y a encore des échanges de code entre XNU et FreeBSD.

Au mieux, c'est un cousin un peu bâtard de la famille BSD.

Ce n'est pas qu'une impression, il n'a pas été conçu pour être publié via http, d'où le protocole homonyme.
Tu as peut-être lu l'introduction de Git présentant les types d'objets de bases: blob, tree, commit et tag. Tu retrouves les mêmes concepts dans Mercurial sous les noms: file, manifest, changeset et tag. Comme dans Git, chaque objet est identifié par un checksum SHA, en interne ça fonctionne quasiment pareil.
Effectivement, Mercurial conserve des diffs des fichiers (texte ou binaire, il ne fait pas la différence) ou delta selon la terminologie de Mercurial.
Quant au versionning de fichiers binaires, les VCS sont conçus pour suivre des fichiers humainement lisible, et les concepts de diffs/merge leurs sont difficilement applicables. C'est même le seul cas à ma connaissance où un VCS traditionnel s'en sort mieux que les VCS distribués de par l'absence de la notion de verrouillage de fichiers (fusionner des modifications concurrentes d'une image par exemple n'a aucun sens). Comment gérer le versionnage des fichiers OpenDocument ? un changement de lettre et pouf tu stockes quasiment tout le document à cause de la compression, comment effectuer un diff/merge efficace ?
Si ça t'intéresse un article sur le versionnage des fichiers odt dans mercurial/git
http://www-verimag.imag.fr/~moy/opendocument/

D'après les benchmarks de git, mercurial est plus efficace que git sur le versionnage de fichiers binaires (c'est avec le pull et le merge, les seuls domaines où mercurial dépasse git niveau performances).
http://git.or.cz/gitwiki/GitBenchmarks

C'est quoi le souci ? Moinsser je veux bien, mais argumenter derrière, c'est mieux.

Encore plus simple à prendre en main, administration quasi-nulle : pas besoin de git repack/prune
Mercurial utilise un protocole basé sur http, support du push inclus. Par défaut, pour la publication de dépôt, c'est du https.
Git est pas très efficace over http, pour la publication de dépôt, il est recommandé de proposer un accès via le protocole Git avec git-daemon. En revanche, pas de push (enfin si, mais sans authentification donc ça revient au même), faut passer par autre chose (comme ssh par exemple) mais c'est pas génant pour un dépôt en lecture seule.
Tu as pléthore de CGI pour publier un dépôt Mercurial (hgwebdir.cgi) ou Git (gitweb.cgi inclus dans la distribution officielle, mais également gitosis, cgit etc ...), donc ça s'interface bien avec un serveur web comme Apache ou lighty.

J'utilise régulièrement les deux, git est extrêmement complet mais plus "rugueux" en terme d'interface utilisateur même si ça c'est beaucoup amélioré depuis, Mercurial offre une interface utilisateur plus cohérente/saine, beaucoup de fonctionnalités équivalentes à Git sont proposés à travers des extensions (souvent incluses dans la distribution standard). Après, c'est les goûts et les couleurs, les deux sont très bien.

En même temps, en continuant de recommander les cartes nVidia, faut se poser la question de quel message on envoit à nVidia mais également ATI et Intel ?
Avant d'acheter une nVidia, faut bien se poser la question de savoir si une ATI ou un chipset Intel ne conviendrait pas avant. Soit on est libriste, soit on est con-sommateur, mais pas seulement encourager les fabricants qui fournissent la documentation, des pilotes libres, il faut leur donner la préférence. On donne un signal fort à ceux qui ne le font pas, à ceux qui sont tentés de le faire également.

Si tu veux juste utiliser un bureau composite, un stupide GMA 950 suffit. Tu veux faire du Blender, c'est compréhensible que tu t'orienterais vers une nVidia haut de gamme. Le but de la manoeuvre ce n'est pas d'être sectaire, mais de faire avancer le logiciel libre.

> NVidia a compris, et pour eux ça marche plutôt bien.
C'est une blague ?

Ça marche tellement bien, que les mises à jours du noyau ou de X cassent régulièrement leurs pilotes propriétaires de merde, qu'ils maintiennent leur propre GL, GLX, ils n'utilisent pas DRI.
Certes, ils sont plutôt réactifs pour des éditeurs propriétaires mais ça reste merdique, tu remercieras les distributeurs qui doivent faire gaffe lors des mises à jours, les empaqueteurs qui font un boulot énorme d'intégration.
Le pilote nVidia (et les autres) qui écrase les libs systèmes, c'est certain, ils ont tout compris et ça marchera très bien jusqu'au jour où tu voudras changer de carte graphique.

Des trois principaux fournisseurs de GPU, nVidia est le moins compatible avec le libre.
ATI joue le jeu, ils ont libérés la documentation, les pilotes Radeon/RadeonHD avancent bien. Intel fournit des pilotes libres pour ses GPU depuis quelques années, ils sont trés actifs dans X, en revanche pas de documentation, le GMA500 (un GPU acheté à PowerVR, une boite d'enflures avec un support Linux et autres systèmes libres de haut vol)

La seule utilité des pilotes propriétaires, c'est de dépanner ceux qui ont la malchance d'avoir du matériel non supporté. Vu la situation, il faut privilégier l'achat de GPU ATI ou Intel (sauf la crotte GMA500) et envoyer chier nVidia.

Je note avec amusement que tout les projets que tu viens de citer ont le même mainteneur upstream (David Zeuthen). :o)

Mais bien sûr, tout les projets qui passent à un cycle de 6 mois le font parce que Shuttleworth l'a dit et c'est lui l'inventeur du concept ! Enfin, peut-être dans le monde de bisounours des fanboys.
La vraie raison, c'est pour éviter les fiasco précédents (roadmap inconsistentes, git cassé, personne ne veut se mouiller pour releaser xserver 1.5 etc ...). Et c'est un développeur Fedora qui propose de passer à un cycle de 6 mois mais aussi d'apprendre à se servir d'un système de contrôle de versions distribués en utilisant cette fonctionnalité mystérieuse (et extrêmement compliqué d'utilisation, surtout dans Git) que sont les branches.
http://lists.freedesktop.org/archives/xorg-devel/2009-Septem(...)

T'as quand même une bonne moitié de contributeurs universitaires dans LLVM.
Les employés d'Apple doivent également partager leur temps dans apple-gcc (ben oui, tant que Clang n'est feature-complete, faut bien faire évoluer le compilo existant)

Le support de C++ a bien avancé dans Clang même si ça n'a pas "quadruplé" (où alors tu n'as pas visité la page depuis très longtemps)
Si tu suis la liste de commits, tu remarqueras un léger coup d'accélérateur depuis fin 2008 notamment de la part des employés d'Apple (dont Douglas Gregor, le plus gros commiter).
Apple pousse de plus en plus llvm dans sa suite de développement et clang a fait son apparition avec l'excellent clang-analyzer (qui a eu un très grand succès auprès des développeurs Fedora :o) ).

llvm-gcc est une solution bâtarde dont le principal intérêt est de tester le backend llvm, et Apple cherche à faire évoluer sa suite de développement en intégrant analyse statique de sources & cie. Le seul frein à la généralisation de Clang est justement le C++, donc ça ne me surprend pas.

> On a l'habitude de tes diatribes aigries dès qu'Ubuntu est mentionné, mais là tu fais fort.

Tu fais bien semblant de confondre Ubuntu et Mark Shuttleworth.
Bizarrement, quand je critiquais Bancilhon (son billet sur l'attribution du marche de l'AN était formidable), on ne m'accusait pas de critiquer Mandriva Linux, quand je critique la direction de Novell ou le CTO de RedHat, personne m'accuse d'être aigri envers OpenSuSE ou Fedora...
Ubuntu est une bonne distribution avec de bonnes idées, mais voilà ce n'est pas la "disruptive innovation" que les fanboys nous rabâchent à longueur de temps. Je critique même des personnages pour qui j'ai le plus grand respect comme RMS, Linus Torvalds, Miguel de Icaza, etc ... La différence avec Mark Shuttleworth, c'est que contrairement aux autres, il n'a aucune légitimité pour parler comme il le fait actuellement.

Au sein d'Ubuntu, il peut jouer au dictateur autant qu'il veut, ailleurs il n'est PERSONNE et rien ne l'autorise à se comporter comme un cowboy mal dégrossi avec les autres communautés.


Mandriva Linux est orienté desktop, Mandriva Linux a beaucoup moins d'utilisateurs qu'Ubuntu, Canonical c'est 200 employés, Mandriva 80 employés dont 50 ingénieurs (chiffres tirés des sites officiels), Mandriva participe infiniment plus aux projets upstreams que Canonical (cf les stats sur les contributeurs au noyau Linux), Mandriva a atteint l'équilibre financier, Mandriva ne prétend pas avoir révolutionné le bureau et ils ont un bon relationnel avec les projets upstreams.
Bizarrement, la réputation de Mandriva en dehors de sa communauté est meilleure que celle de Canonical/Ubuntu.


> Si il était si incompétent, la communauté Ubuntu ne serait pas la plus importante des communautés de distributions.

... et Canonical ne serait pas dans le rouge au point de lancer cette pantalonnade désespérée de synchronisation des distributions.

Je ne nie pas son habilité à faire du buzz, la pseudo-philosophie d'ubuntu (dont on n'entend plus parler), les CD à gogo, et le fameux code de conduite digne d'une école de maternelle.

-------

Ubuntu est très populaire mais les chiffres de 8 puis 12 millions d'utilisateurs donnés par Mark S.semble très farfelus vu que Canonical ne communique aucunes données ni même la méthode utilisée pour comptabiliser le nombre d'utilisateurs.

FedoraProject a lancé un projet statistiques, l'objectif étant de comptabiliser le nombre d'utilisateurs de Fedora, et les machines utilisés. Les données sont régulièrement actualisés et mise à la disposition de tout le monde.
https://fedoraproject.org/wiki/Statistics

Le but n'étant pas de faire une course de "bites" mais de mieux gérer les ressources disponibles (rien ne sert de passer 30% de son temps sur une architecture < 1% d'utilisateurs par exemple), et de convaincre les fabricants/développeurs que GNU/Linux est un marché viable et digne d'intérêt.
https://fedoraproject.org/wiki/Infrastructure/Metrics

Une des retombées de ce projet, c'est smolt qui a permis l'établissement de la base de données matérielle sous GNU/Linux la plus extensive qui soit. Les autres distributions, Ubuntu y compris ont été invités mais seul OpenSuSE a accepté l'invitation.
http://smolts.org

Think accessibility.

Suffisamment compétents pour que leurs sociétés aient atteint un équilibre financier, suffisamment humbles pour ne pas nous casser les burnes avec leurs "visions" et l'imposer aux communautés.
Sans oublier la différence dans le discours, lui, il arrive comme un cow-boy et demande à la communauté de se soumettre à ses caprices, la première chose qu'une vice-présidente de Novell trouve à dire à la communauté lors d'une conférence sur OOo (Novell est un gros contributeur à OOo) c'est de remercier les contributeurs pour leur travail.

Il ferait mieux de se cantonner à son rôle de dirigeant de boîte et de laisser Jono Bacon et les autres managers gérer la partie communautaire.

> Mark S. plaide juste pour avoir la même cadence et l'avoir de façon synchronisée.

Je ne nie pas l'intérêt pour un projet d'avoir une roadmap bien définie, mais vouloir caler TOUT les projets sur le même rythme est impossible et même stupide.
Puis, il est très mal placé pour faire cette proposition, Canonical est quasi inexistante dans les projets upstreams, il a refusé de participer à Debian Common Core et sa réponse a été de suggérer aux distributions debian-based de se caler sur Ubuntu ! Avant de demander aux autres de faire l'effort, à lui de montrer l'exemple !
Sa proposition, ce n'est pas une meilleure collaboration entre les projets mais visiblement de satisfaire ses caprices. Il n'arrive pas à suivre la cadence, du moins sans avoir à embaucher des développeurs, des testeurs etc... pour travailler plus en upstream.
La prochaine étape, c'est évidemment la même plateforme de travail, SCM, traduction, etc... ne pensez pas à Bazaar, Rosetta ou bien même Launchpad.

C'est du logiciel libre, baby, seuls ceux qui contribuent ont voix au chapitre.

> Est-ce que la qualité de la version beta en cours de développement est-elle suffisante pour l'intégrer dans ma distribution?

Ce n'est pas aux projets upstream de se caler sur les intégrateurs mais l'inverse. Une autre manière d'influer sur la qualité du logiciel, c'est tout simplement de participer ! Faire des tests, écrire du code, organiser des échanges entre les développeurs etc...

Synchroniser les cadences est clairement impossible, les projets sont très différents, ils ont des rythmes très différents. Mark S. se bat clairement contre des moulins à vents.
En revanche, ce qu'il est très possible de faire, c'est de faire collaborer les différents projets sur un objectif commun (ex: KMS avec XOrg, Linux), de faire tourner les espaces d'échanges (FreeDesktop, aKademy+GUADEC == Gran Canaria Desktop Summit ).
Le préalable, c'est de participer activement en upstream, de mettre à disposition des projets des contributeurs, tout ce que Canonical ne fait pas justement ou si peu.
Ce serait trop beau, si tout les projets acceptaient de se mettre à ses ordres sans contrepartie aucune.

Enfin, c'est donner trop de crédit à un mec qui "joue" au guru visionnaire, il ne fait que brasser de l'air. Promettre de soutenir Nouveau (on attend toujours hein), promettre de fmettre à disposition de GNOME des ergonomes et des graphistes, faire un "AppStore-like" (en gros, un joli gestionnaire de dépendances graphiques basés sur PackageKit), synchroniser les projets/distros sans contrepartie de sa part.

Ubuntu est dirigé par un clown mégalomane et incompétent dans la gestion d'une distribution communautaire.

Chez moi, PA au repos, 0% CPU, 6.5Mo en RAM, je lance une vidéo, ça monte à 5% (tout compris) et 17Mo en RAM. La machine est un quad core qui tourne depuis plus d'un mois.
C'est pas extravagant, PA c'est un process supplémentaire donc forcément ça bouffe plus de ressources, ça a pas mal évolué en 2 ans. Par contre, sur certaines machines, la conso CPU reste affolante mais si personne n'aide à identifier le problème, on risque pas d'aller bien loin.

> C'est Alsa qui faut revoir.
Certes, Alsa et les pilotes ont sérieusement besoin d'un bon coup de polish.
Alsa c'est très bas niveau, ça ne dispense pas d'avoir une API plus haut niveau.

> Je reste toujours sur le cul que justement cela soit Fedora qui est intégré ce truc là
Là, je t'arrête, intégrer des nouvelles technologies et les aider à atteindre leur maturité le plus rapidement possible c'est LA mission de FedoraProject.
En plus, le mainteneur upstream est également le mainteneur dans Fedora (et il fait très bien son boulot en tant qu'intégrateur, une cassure au tout début en 2 ans) donc les correctifs ont été très rapidement intégré. En revanche, les distributions se sont ruées dessus trop tôt contrairement aux recommandations de L. Poettering.