> Les licences sont comparrables mais pas le but final. L'un est la performance, l'autre l'éthique.
C'est du n'importe quoi comme justification.
Et si on suit ta justification alors la GPL est la plus performante. Sans discussion possible. Linux est sous GPL, Gnome est sous GPL, gcc sous GPL, etc...
Le but de l'Open Source, c'est d'avoir les sources et de pouvoir "jouer" avec. Le but de la FSF, et de la GPL évidemment, c'est de "libérer les utilisateurs". Et entre autres des breverts ce que ne fait pas l'OSI.
> Pas mal, mais du coup on perd en "spontanéité" : impossible de changer de chaine par exemple.
Je vois ce que tu veux. Je ne suis pas un "zappeur" :-)
En général j'enregistre (mplayer -dumpstream ... ou avec mencoder comme tu l'indique), puis je regarde. Parfois je regarde avant que l'enregistrement soit terminé (d'où le tail -f).
> Et puis on se retrouve vite avec un dump énorme
Oui. Mais les disques sont tellement énormes aujourd'hui...
> Un mplayer dvb:// -cache 250000 directement permet de changer de chaine
Le problème est que dans ce cas, si tu fais pause et que le cache devient plein, l'acquisition est suspendue. Avec ma "solution" ce n'est pas le cas. Je ne perd rien. Et si c'est un bon film, je peux le stocker dans un coin et le regarder une seconde fois (ou le partage avec un pote, de façon tout à fait légale).
> Autrement dit ça sert a quoi " tail --bytes=`echo 2^40 | bc` -f tv.dump | " ?
Si tu fais un "mplayer tv.dump", mplayer s'arrête s'il atteind la fin de fichier.
Avec "tail -f ...", il n'y a pas de fin de fichier. Si tail voit une fin de fichier, il attend (c'est paramétrable avec --sleep-interval) et regarde si des données ont été ajouté à la fin du fichier.
Avec ce que j'ai donné, on peut "naviger". Si on va au-delà de la fin du fichier, mplayer attend les données (qui seront fournit par tail au fur et à mesure que "mplayer -dumpstream ..." les récupères de la carte dvb (ou autre)).
> Bon manquerais l'enregistrement sur pause du coup.
Avec mplayer et pour dvb, je fais très simplement. Certes, il faut taper des lignes de commande, mais ça marche. NB: des scripts simplissimes rendent la chose moins fastidieuse.
// L'acquisition et enregistrement dans un fichier.
// Commande à taper dans un terminal.
// Enregistre dans le fichire tv.dump
$ mplayer .... -dumpstream -dumpfile tv.dump "dvb://ARTE"
// la visualisation
// Commande à taper dans un autre terminal
$ tail --bytes=`echo 2^40 | bc` -f tv.dump | mplayer ... -
Le "`echo 2^40 | bc`" est pour avoir un gros nombre.
Le '-' final indique qu'il faut utilser l'entrée standard.
Si on a beaucoup de mémoire on peut faire "mplayer -cache 250000 -". Ainsi on peut aussi revenir en arrière de 2 ou 3 minutes. C'est que du bonheur.
J'ai 512 Mo, j'utilise avec "mplayer -cache 250000".
L'interface graphique je m'en fous. Mais je comprend que tout le monde n'aime pas la ligne de commande.
> mplayer est vraiment un très bon lecteur
Ce n'est pas qu'un lecteur. Il peut être utilisé pour regarder la tv (v4l, dvb) et pour coder des vidéos. Il fait aussi du processing (crop, redimensionnement, filtrage, désentrelacement, etc).
Je l'utilise depuis des années et je l'adore. M'enfin, je ne pense pas que mplayer soit pour le linux "pour les masses". Qu'importe, je le kiffe grave.
en informatique, la compilation est le travail réalisé par un compilateur qui consiste à transformer un code source lisible par un humain en un fichier binaire exécutable par une machine
Le programme en langage machine produit par un compilateur est appelé code objet.
[...]
Structure d'un compilateur
La tâche principale d'un compilateur est de produire du code objet correct.
[...]
Compilateur croisé
Un compilateur croisé (en anglais cross compiler) est un programme capable de traduire un code source en code objet
[...]
Byte code ou code octet
[...]
C'est le cas du compilateur Java, qui traduit du code Java en bytecode Java (code objet).
Pour moi, la compilation c'est partir d'un fichier source (généralement comprehensible par un humain) qui ne peut être "exécuté" vers un code objet qui peut être exécuté (compréhensible par un cpu typiquement). Code objet natif (par exemple il peut être exécuter directement par un i386) ou code objet qui sera exécuté par une "machine virtuelle" (typiquement java, etc).
Notons que le compilateur java gcj peut produire du natif ou pour machine virtuel (quoique je n'en suis pas sûr ; quelqu'un pour confirmer ou infirmer ?).
L'édition de lien ne fait pas parti de la compilation car l'édition de lien ne produit pas de code machine. L'édition de lien donne des informations (comment lancer le code objet, à quelle adresse est la fonction bidule, etc).
Le language assembleur est compréhensible par un humain (OK, ils ne sont pas nombreux :-)). L'assembleur n'est pas compréhensible par le cpu (ou une machine virtuelle) et donc n'est pas du code object. On trouve de l'assembleur dans Linux. Cette assembleur doit être compilé (le terme assemblé me convient aussi). L'assembleur, pour un compilateur C par exemple, est généralement une étape intermédiaire lié à l'implémentation du compilateur. Un compilateur pourrait produire du code object directement et ça resterait un compilateur. Un "compilateur" (notez les guillements) qui ne fait que traduire du C (par exemple) à l'assembleur n'est pas un compilateur. Ce qui est produit ne peut être exécuté (lu par un cpu typiquement).
> « La transformation du code assembleur en langage machine est accomplie par un programme nommé assembleur, dans l'autre sens par un programme désassembleur. Les opérations s'appellent respectivement assemblage et désassemblage. »
Ça OK. Mais ce qui fait le passage de assembleur à code objet peut aussi est appelé un compilateur.
Mais la dénomination assembleur est bonne car, comme tu le pointes, on peut désassembler (avec quelques perte d'info comme les noms de variable). Il est rare qu'on puisse remonter au C depuis le code objet.
Notons qu'il y a (avait) des compilateurs C++ qui générait du C puis compilait le C.
Mais ce qui permet de passer de C++ à code objet, qu'il passer ou non par les languages intermédiaires C et assembleur, est un compilateur. Les formes intermédiaires sont des "détails" d'implémentations.
Un programme qui ne produit que de l'assembleur (et jamais de code objet) n'est pas un compilateur (selon moi).
> GTK signifie Gimp ToolKit et n'a rien à voir avec Gnome...
Pourtant il me semble que c'est massive utilisé par Gnome et principalement (pour ne pas dire exclusivement) développé par Gnome.
Sinon oui GTK signifie Gimp ToolKit et GTK a ses origines dans le projet Gimp. Merci Gimp.
> Chargé les libs Gnome en mémoire... pour ne pas l'utiliser par la suite, c'est vraiment regrettable...
Le lib ne sont chargées que si tu les utilises. Et n'est chargé que la partie de la lib que tu utilises. Idem pour les exécutables. N'est chargé que s'il faut excécuter le code. C'est cette "feature" qui permet d'avoir le splash screen très tôt.
> terminologie courante à l'époque où on écrivait des programmes entiers en ASM
Et aujourd'hui tu dis quoi quand tu compiles^Wje_ne_sais_quoi un fichier C avec gcc pour avoir du code object ?
Moi je compile. Et toi ? Tu compiles-assembles ?
Il est aussi que Dell travail sur/avec Linux depuis des années et que Ubuntu a rendu ce travail plus visible (par forcément plus intense).
En effet, c'est fait depuis des années que Dell bosse avec Red Hat et Novell.
Je dis ça car parfois on a l'impression qu'avant Ubuntu il n'y avait rien.
En passant, tu noteras que "mon" spécialiste passe aussi par le menu les défauts de SeLinux. Trop compliqué, nécessaire des outils de haut niveau. Très limité pour NFS et pour longtemps. Support incomplet pour tout ce qui est réseau (mais bien mieux que AppArmor) mais ça progresse (et vite).
> Oui, mais une personne spécialiste du sujet aura toujours un avis bien argumenté, on peut faire la même avec les OGM.
Je crois qu'il ne faut pas tout mélanger et tu fais "insulte" aux spécialites des OGM. Beaucoup sont contre certaines exploitations car ils sont très bien placé pour en évaluer les risques. L'avis d'une entreprise qui fait des OGM n'est pas forcément un avis de spécialiste mais un avis du marketing qui veut faire du pognon.
Si MS donne son avis sur les brevets, ce n'est pas un avis de spécialiste sur les brevets mais un avis sur les brevets d'une boite qui veut faire du pognon avec les brevets. C'est très différent même si MS a des spécialistes en brevets.
Enfin, un "spécialiste" a une démarche scientifique, argumenté de façon rigoureuse. Il se base sur des faits et non des croyances. Et lorsqu'il utilise des croyances (pour faire des projections dans l'avenir par exemple) il dit que ce sont des croyances et non des faits démontrés scientifiquement.
> je dis juste qu'on a un seul point de vue
Il est beaucoup partagé. Mais OK, les liens donnés son l'avis d'une personne.
> c'est comme si tu ne prenais que le point de vue de Sarko pour défendre ou critiquer le communisme.
Sarko n'est pas un spécialiste du communisme. On parle de sécurité, je donne l'avis d'un spécialiste en sécurité. Certe, ce n'est pas un spécialiste de AppArmor. Mais Sarko n'est pas un politologue (une personne avec une démarche scientifique) mais un politique.
> De plus, les liens datent de mars 2006, parfois les choses évoluent et des erreurs se corrigent.
Peut-être pas aussi vite...
> Si j'ai lu wikipedia, c'est que je pense que c'est un carrefour d'opinions relativement mis à jour (la preuve, le fait que le développeur soit viré a été intégré à l'article), et c'est souvent plus la page de discussion qui m'intéresse que l'article en lui même.
Je ne remet pas en cause wikipedia. C'est une excellente source d'information. Incontournable.
> C'est à propos du réflexe primaire anti-red-hat auquel tu as fait allusion
C'est pour une distribution qui a une certaine tradition dans ce domaine.
> preuve que le programme va fonctionner sans problème.
Surtout que tu vas être quasi obligé d'utiliser Windows. C'est une garantit supplémentaire à ne pas négliger sans compter toutes les innovations brevetés qu'apportent MS.
Merci pour la réponse mais "mouaif".
Un compilateur C va passer du C à l'assembleur. On dit (il me semble) qu'il fait une traduction du C vers l'assembleur (puis de l'assembleur vers de l'objet mais dans ce cas c'est assez proche de la définition de transcodage que tu donnes)
> — la traduction implique une interprétation (sémantique)
Ça me semblait nécessaire pour traduire/transcoder du Cobol vers du java.
Selon ce lien, utiliser transcodage pour, par exemple, de la conversion de bmp à gif est sensé. Pour Cobol à Java ça ne me parait pas évident. M'enfin, je ne connais pas Cobol, très peu Java et je ne sais pas ce que fait le projet NACA.
Je ne suis pas un spécialiste sécurité, donc mon avis peut être mis en doute. C'est évident.
> >>Novell will continue updating AppArmor
Mouaif, la parole de Novell....
Et pourquoi Novell ne vire pas tous ses développeurs Linux, OOo, etc dans ce cas ?
Mais, et c'est un fait, AppArmor a été refusé pour l'inclusion dans Linux. C'est une décision de spécialistes. Il n'a pas été refusé car le code n'était pas propre, etc. Il a été refusé car, toujours pour faire court, AppArmor sucks. Non qu'il ait des bugs, mais il n'est pas une bonne réponse aux problèmes de sécurité, il a trop de problèmes de conception.
> Dans ce cas, tu devrais te dépêcher de modifier l'article de Wikipedia
Sur Wikipedia, et je respecte ça n'en doute pas, toutes les voix comptes. Sur lkml, il n'y a que ceux qui ont fait leur preuve (c-à-d du code notamment) qui sont écouté.
Wikipedia n'est pas de l'avis de Linux, OK, faut faire avec, pas de problème. D'autant plus que l'article de Wikipedia donne un pointeur sur la discussion sur la lkml qu'il y a eu autour de AppArmor.
> Il y a encore beaucoup de discussions, sur la validité d'un choix de sécurité par les chemins ou par les inodes
Chez les spécialistes, je ne crois pas. La communauté de spécialiste autour de SeLinux est bien plus importante que pour AppArmor. Ce n'est pas un hazard.
Si ta question est "Pour l'utilisateur/administrateur final, vaut-il mieux AppArmor ou SeLinux ?", je n'ai pas de réponse.
Tout dépend d'un faisceau de chose.
AppArmor est plus simple, mais ne fait pas de flow control (ou c'est très limité). AppArmor ne peut pas être utilisé dans ce cas. Mais celui qui n'a pas besoin de ça s'en fout et peut utiliser AppArmor.
AppArmor ne peut pas faire de MLS. C'est utilisé par des adminstrations américaines. Donc pour ces dernières AppArmor ne peut être utilisé.
SeLinux est plus compliqué à mettre en oeuvre. J'utilise une distribution avec SeLinux. Que SeLinux soit compliqué, je m'en fous. Il est activité, je n'y touche pas. AppArmor ne m'apporterait rien et en plus il est moins "puissant" que SeLinux.
SeLinux commence son stade de simplification d'administration par l'utilisateur. C'est un début. A l'avenir il sera peut-être aussi simple de faire de chose simple avec SeLinux qu'avec AppArmor.
Mais, je crois définitivement que la conception d'AppArmor est moins bonne que SeLinux sur le plan sécurité. C'est mon avis et je ne suis pas un spécialiste. Mais j'ai pris la peine de m'informer (voir les liens que j'ai donné, que tu devrais aussi lire au-lieu de te limite à wikipedia).
> 1) arrêtons de nourrir les trolls basés sur l'imagination, fournissons de véritables éléments de comparaison
Voir les liens que j'ai donné.
> 2) arrêtons les délires sur les contre-projets de projets
???
> 3) >>> "On est rebelz ou on ne l'est pas, après tout." Arrêtons ces phrase sans intérêt dignes de jeunes de 13 ans.
Va lire les liens que j'ai donné au-lieu de faire un blocage sur une phrase.
On ne peut pas avoir le beurre et l'argent du l'argent :-)
> Du coup, l'utilisateur "personnel" (i.e. à la maison)
Lequel ?
Madame Michu ?
Pour un utilisateur, c'est toujours du boulot que de suivre les évolutions d'un projet dynamique. Ce n'est pas spécifique à Linux.
Madame Michu ne doit pas utiliser kernel.org, mais une distribution avec du support.
> un 2.6-quelquechose et ce quelque chose varie d'une distribution à l'autre.
Ce n'est pas un problème Linux. C'est le libre, c'est le choix des distributions.
Par exemple RHEL 5 (et ses clones) utilise un 2.6.18 (et sur toute la durée de vie de RHEL 5, c-à-d au moins 7 ans). Libre à toute distribution d'utiliser aussi le 2.6.18. Mais (et ce n'est pas un reproche) elles préfèrent prendre la dernière version lorsqu'une distribution est en gestation (exactement comme le fait Red Hat).
Il y a de bonnes raisons à ça et ce n'est pas que pour la frime. C'est aussi pour avoir le support de la communauté des développeurs Linux lors de la gestation de la distribution (les développeurs ont le nez dans la dernière version, pas dans les vieilles versions).
Il n'y a pas de solution unique au désagrément du modèle de développement de Linux. S'il y a une solution uniquement, c'est d'avoir les drivers en libre et upstream.
Mais voyons aussi ce qu'a apporté l'évolution rapide de Linux et qui répond à ton soucis. Aujourd'hui Linux marche "les doigts dans le nez". A l'époque de Linux 2.0, 2.2 et même le 2.4 (sauf peut-être les dernières versions de 2.4) beaucoup d'utilisateurs devaient recompiler le noyau, faire un checkout d'un CVS pour avoir un driver pour leur carte télé, etc...
Ce que je veux dire, c'est que remettre en cause la rapidité de développement de Linux (c-à-d aussi son modèle de développement), c'est aussi reppousser le moment où on a la solutions qui va bien (pour une carte télé qui marche "les doigts dans le nez", etc).
Aujourd'hui très peu recompile leur noyau, c'est aussi grace au modèle de développement de Linux. Certe, de façon indirect.
> De même, l'utilisateur "professionnel" (i.e. en entreprise et/ou développeur pour Linux) ne bénéficie plus de cette pérennité connue avec les noyaux <= 2.4 et le diagnostic est d'autant plus difficile.
Le professionnel veut une garantie de service (c'est-à-dire du support). Donc il prend (ou devrait prendre) une distribution professionelle (ou un clone de distribution professionnel s'il ne veut pas de support mais seulement la stabilité de l'api) et ne pas se poser de question et ne pas demander l'impossible à Linux (le Linux upstream). Linux ne peut pas évoluer vite (ce qui est hypra important sinon Linux est dépassé par les autres et ne répond pas aux attentes) et être figé.
Kernel.org n'a pas pour cible Madame Michu ni les professionnels.
> d'un certain nombre de logiciels/technos à côté (genre udev, dbus...).
Ces technos étaient en développement intensif. Ça devrait se calmer.
Notons que le libre est ouvert. Donc les technos en pleine gestation sont disponibles (ça a les inconvéniants de ses qualités).
> Bref, hors développeurs du noyau lui-même, il n'y a pas que des avantages.
Il faut penser à l'offre de GNU/Linux globalement. kernel.org n'est "que" le développement.
Si tu veux du stable (api), tu trouves.
Si tu veux du "chaud", tu trouves aussi.
Comme l'a faire remarquer le GeneralZod (c'était toi ?), beaucoup utilisent Fedora (c'est "chaud", c'est pour le développement, c'est pour la veille technologique, etc) ET RHEL ou ses clones (c'est "froid", ça ne bouge pas, c'est sans intérêt pour la veille technologique, etc). Il faut deux distributions (ou plus de façon plus générale) car il y a des objectifs d'utilisation incompatibles.
Linux (de kernel.org) ne peut pas répondre aux utilisateurs type Fedora et aux utilisateurs type RHEL (ou Debian stable ou Mandriva CS etc). C'est impossible.
> Apache/ProXad » vous rajoutent un magnifique cadre avec une belle pub
Tout simplement scandaleux.
Déjà que free me donne rien pour avoir l'honneur d'héberger mes pages et ma base de donnée sur leurs putain de bécanes !
C'est décidé, je vais les héberger moi même mes pages.
Free peut toujours me souplier à genoux de rester, c'est décidé, je me casse.
[^] # Re: Open Source
Posté par IsNotGood . En réponse au journal L'OSI approuve deux des licences microsoft. Évalué à 2.
C'est du n'importe quoi comme justification.
Et si on suit ta justification alors la GPL est la plus performante. Sans discussion possible. Linux est sous GPL, Gnome est sous GPL, gcc sous GPL, etc...
Le but de l'Open Source, c'est d'avoir les sources et de pouvoir "jouer" avec. Le but de la FSF, et de la GPL évidemment, c'est de "libérer les utilisateurs". Et entre autres des breverts ce que ne fait pas l'OSI.
[^] # Re: Open Source
Posté par IsNotGood . En réponse au journal L'OSI approuve deux des licences microsoft. Évalué à -2.
Non.
Je n'ai pas envis d'expliquer pourquoi car ça a déjà été discuter 3000 fois ici et, surtout, j'ai la flemme.
Pour l'anecdote, RMS utilise parfois une signature dans ce goût :
- "Celui qui appartient à un autre mouvement que l'Open Source".
# Open Source
Posté par IsNotGood . En réponse au journal L'OSI approuve deux des licences microsoft. Évalué à 4.
[^] # Re: À quand la 1.0
Posté par IsNotGood . En réponse au journal MPlayer 1.0 RC2 dispo. Évalué à 1.
Je vois ce que tu veux. Je ne suis pas un "zappeur" :-)
En général j'enregistre (mplayer -dumpstream ... ou avec mencoder comme tu l'indique), puis je regarde. Parfois je regarde avant que l'enregistrement soit terminé (d'où le tail -f).
> Et puis on se retrouve vite avec un dump énorme
Oui. Mais les disques sont tellement énormes aujourd'hui...
> Un mplayer dvb:// -cache 250000 directement permet de changer de chaine
Le problème est que dans ce cas, si tu fais pause et que le cache devient plein, l'acquisition est suspendue. Avec ma "solution" ce n'est pas le cas. Je ne perd rien. Et si c'est un bon film, je peux le stocker dans un coin et le regarder une seconde fois (ou le partage avec un pote, de façon tout à fait légale).
[^] # Re: À quand la 1.0
Posté par IsNotGood . En réponse au journal MPlayer 1.0 RC2 dispo. Évalué à 2.
Si tu fais un "mplayer tv.dump", mplayer s'arrête s'il atteind la fin de fichier.
Avec "tail -f ...", il n'y a pas de fin de fichier. Si tail voit une fin de fichier, il attend (c'est paramétrable avec --sleep-interval) et regarde si des données ont été ajouté à la fin du fichier.
Avec ce que j'ai donné, on peut "naviger". Si on va au-delà de la fin du fichier, mplayer attend les données (qui seront fournit par tail au fur et à mesure que "mplayer -dumpstream ..." les récupères de la carte dvb (ou autre)).
[^] # Re: À quand la 1.0
Posté par IsNotGood . En réponse au journal MPlayer 1.0 RC2 dispo. Évalué à 3.
Avec mplayer et pour dvb, je fais très simplement. Certes, il faut taper des lignes de commande, mais ça marche. NB: des scripts simplissimes rendent la chose moins fastidieuse.
// L'acquisition et enregistrement dans un fichier.
// Commande à taper dans un terminal.
// Enregistre dans le fichire tv.dump
$ mplayer .... -dumpstream -dumpfile tv.dump "dvb://ARTE"
// la visualisation
// Commande à taper dans un autre terminal
$ tail --bytes=`echo 2^40 | bc` -f tv.dump | mplayer ... -
Le "`echo 2^40 | bc`" est pour avoir un gros nombre.
Le '-' final indique qu'il faut utilser l'entrée standard.
Si on a beaucoup de mémoire on peut faire "mplayer -cache 250000 -". Ainsi on peut aussi revenir en arrière de 2 ou 3 minutes. C'est que du bonheur.
J'ai 512 Mo, j'utilise avec "mplayer -cache 250000".
[^] # Re: À quand la 1.0
Posté par IsNotGood . En réponse au journal MPlayer 1.0 RC2 dispo. Évalué à 3.
> mplayer est vraiment un très bon lecteur
Ce n'est pas qu'un lecteur. Il peut être utilisé pour regarder la tv (v4l, dvb) et pour coder des vidéos. Il fait aussi du processing (crop, redimensionnement, filtrage, désentrelacement, etc).
Je l'utilise depuis des années et je l'adore. M'enfin, je ne pense pas que mplayer soit pour le linux "pour les masses". Qu'importe, je le kiffe grave.
[^] # Re: Globalement
Posté par IsNotGood . En réponse au journal Entretien avec John Hull, le Manager Linux de chez Dell. Évalué à -1.
Avec 1 %, Ubuntu est aussi une distribution de niche (comme Linux pour le desktop).
[^] # Re: Compile "plus de bruit"
Posté par IsNotGood . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à 1.
Et je ne suis pas le seul à le penser (aucun commentaire n'est de moi :-) ; pas encore) :
http://fr.wikipedia.org/wiki/Discuter:Compilateur
[^] # Re: Compile "plus de bruit"
Posté par IsNotGood . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à -1.
Ok avec toi, je t'accorde trop d'importance.
> si tu penses que les articles sont mal fichus et mensongers
J'ai dit "pas clair".
Je t'accorde beaucoup trop d'importance.
[^] # Re: Compile "plus de bruit"
Posté par IsNotGood . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à -2.
J'ai dit "blabla ... pour avoir du code objet ?".
Je n'ai pas dit "blabla .. pour avoir un exécutable ?".
L'exécutable est la forme que l'OS peut charger et lancer l'exécution.
> De même pour le préprocessing.
Le préprocessing peut faire parti de la compilation (et en général il fait parti de la compilation).
> D'ailleurs toutes ces tâches sont effectuées par des exécutables séparés
Ce qui est un "détail" d'implémentation.
> http://fr.wikipedia.org/wiki/Compilateur
L'article ne me parait par clair.
http://fr.wikipedia.org/wiki/Compilation (c'est un résumé)
http://fr.wikipedia.org/wiki/Compilateur
Pour moi, la compilation c'est partir d'un fichier source (généralement comprehensible par un humain) qui ne peut être "exécuté" vers un code objet qui peut être exécuté (compréhensible par un cpu typiquement). Code objet natif (par exemple il peut être exécuter directement par un i386) ou code objet qui sera exécuté par une "machine virtuelle" (typiquement java, etc).
Notons que le compilateur java gcj peut produire du natif ou pour machine virtuel (quoique je n'en suis pas sûr ; quelqu'un pour confirmer ou infirmer ?).
L'édition de lien ne fait pas parti de la compilation car l'édition de lien ne produit pas de code machine. L'édition de lien donne des informations (comment lancer le code objet, à quelle adresse est la fonction bidule, etc).
Le language assembleur est compréhensible par un humain (OK, ils ne sont pas nombreux :-)). L'assembleur n'est pas compréhensible par le cpu (ou une machine virtuelle) et donc n'est pas du code object. On trouve de l'assembleur dans Linux. Cette assembleur doit être compilé (le terme assemblé me convient aussi). L'assembleur, pour un compilateur C par exemple, est généralement une étape intermédiaire lié à l'implémentation du compilateur. Un compilateur pourrait produire du code object directement et ça resterait un compilateur. Un "compilateur" (notez les guillements) qui ne fait que traduire du C (par exemple) à l'assembleur n'est pas un compilateur. Ce qui est produit ne peut être exécuté (lu par un cpu typiquement).
> « La transformation du code assembleur en langage machine est accomplie par un programme nommé assembleur, dans l'autre sens par un programme désassembleur. Les opérations s'appellent respectivement assemblage et désassemblage. »
Ça OK. Mais ce qui fait le passage de assembleur à code objet peut aussi est appelé un compilateur.
Mais la dénomination assembleur est bonne car, comme tu le pointes, on peut désassembler (avec quelques perte d'info comme les noms de variable). Il est rare qu'on puisse remonter au C depuis le code objet.
Notons qu'il y a (avait) des compilateurs C++ qui générait du C puis compilait le C.
Mais ce qui permet de passer de C++ à code objet, qu'il passer ou non par les languages intermédiaires C et assembleur, est un compilateur. Les formes intermédiaires sont des "détails" d'implémentations.
Un programme qui ne produit que de l'assembleur (et jamais de code objet) n'est pas un compilateur (selon moi).
[^] # Re: De toute façon...
Posté par IsNotGood . En réponse au journal De l'utilité de Xubuntu. Évalué à 3.
Pourtant il me semble que c'est massive utilisé par Gnome et principalement (pour ne pas dire exclusivement) développé par Gnome.
Sinon oui GTK signifie Gimp ToolKit et GTK a ses origines dans le projet Gimp. Merci Gimp.
> Chargé les libs Gnome en mémoire... pour ne pas l'utiliser par la suite, c'est vraiment regrettable...
Le lib ne sont chargées que si tu les utilises. Et n'est chargé que la partie de la lib que tu utilises. Idem pour les exécutables. N'est chargé que s'il faut excécuter le code. C'est cette "feature" qui permet d'avoir le splash screen très tôt.
[^] # Re: transcodage ?
Posté par IsNotGood . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à 1.
Et aujourd'hui tu dis quoi quand tu compiles^Wje_ne_sais_quoi un fichier C avec gcc pour avoir du code object ?
Moi je compile. Et toi ? Tu compiles-assembles ?
[^] # Re: transcodage ?
Posté par IsNotGood . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à 2.
Ça tient debout. Merci.
[^] # Re: transcodage ?
Posté par IsNotGood . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à 1.
[^] # Re: Globalement
Posté par IsNotGood . En réponse au journal Entretien avec John Hull, le Manager Linux de chez Dell. Évalué à 8.
En effet, c'est fait depuis des années que Dell bosse avec Red Hat et Novell.
Je dis ça car parfois on a l'impression qu'avant Ubuntu il n'y avait rien.
[^] # Re: Novell se désengage de AppArmor ?
Posté par IsNotGood . En réponse au journal AppArmor is teh lulz. Évalué à 1.
[^] # Re: Novell se désengage de AppArmor ?
Posté par IsNotGood . En réponse au journal AppArmor is teh lulz. Évalué à 2.
Je crois qu'il ne faut pas tout mélanger et tu fais "insulte" aux spécialites des OGM. Beaucoup sont contre certaines exploitations car ils sont très bien placé pour en évaluer les risques. L'avis d'une entreprise qui fait des OGM n'est pas forcément un avis de spécialiste mais un avis du marketing qui veut faire du pognon.
Si MS donne son avis sur les brevets, ce n'est pas un avis de spécialiste sur les brevets mais un avis sur les brevets d'une boite qui veut faire du pognon avec les brevets. C'est très différent même si MS a des spécialistes en brevets.
Enfin, un "spécialiste" a une démarche scientifique, argumenté de façon rigoureuse. Il se base sur des faits et non des croyances. Et lorsqu'il utilise des croyances (pour faire des projections dans l'avenir par exemple) il dit que ce sont des croyances et non des faits démontrés scientifiquement.
> je dis juste qu'on a un seul point de vue
Il est beaucoup partagé. Mais OK, les liens donnés son l'avis d'une personne.
> c'est comme si tu ne prenais que le point de vue de Sarko pour défendre ou critiquer le communisme.
Sarko n'est pas un spécialiste du communisme. On parle de sécurité, je donne l'avis d'un spécialiste en sécurité. Certe, ce n'est pas un spécialiste de AppArmor. Mais Sarko n'est pas un politologue (une personne avec une démarche scientifique) mais un politique.
> De plus, les liens datent de mars 2006, parfois les choses évoluent et des erreurs se corrigent.
Peut-être pas aussi vite...
> Si j'ai lu wikipedia, c'est que je pense que c'est un carrefour d'opinions relativement mis à jour (la preuve, le fait que le développeur soit viré a été intégré à l'article), et c'est souvent plus la page de discussion qui m'intéresse que l'article en lui même.
Je ne remet pas en cause wikipedia. C'est une excellente source d'information. Incontournable.
> C'est à propos du réflexe primaire anti-red-hat auquel tu as fait allusion
C'est pour une distribution qui a une certaine tradition dans ce domaine.
[^] # Re: Et dotNET alors ?
Posté par IsNotGood . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à 2.
Surtout que tu vas être quasi obligé d'utiliser Windows. C'est une garantit supplémentaire à ne pas négliger sans compter toutes les innovations brevetés qu'apportent MS.
[^] # Re: transcodage ?
Posté par IsNotGood . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à 2.
Un compilateur C va passer du C à l'assembleur. On dit (il me semble) qu'il fait une traduction du C vers l'assembleur (puis de l'assembleur vers de l'objet mais dans ce cas c'est assez proche de la définition de transcodage que tu donnes)
> — la traduction implique une interprétation (sémantique)
Ça me semblait nécessaire pour traduire/transcoder du Cobol vers du java.
> http://atilf.atilf.fr/dendien/scripts/fast.exe?transcodage
Selon ce lien, utiliser transcodage pour, par exemple, de la conversion de bmp à gif est sensé. Pour Cobol à Java ça ne me parait pas évident. M'enfin, je ne connais pas Cobol, très peu Java et je ne sais pas ce que fait le projet NACA.
[^] # Re: Et dotNET alors ?
Posté par IsNotGood . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à 6.
[^] # Re: Novell se désengage de AppArmor ?
Posté par IsNotGood . En réponse au journal AppArmor is teh lulz. Évalué à 1.
> >>Novell will continue updating AppArmor
Mouaif, la parole de Novell....
Et pourquoi Novell ne vire pas tous ses développeurs Linux, OOo, etc dans ce cas ?
Mais, et c'est un fait, AppArmor a été refusé pour l'inclusion dans Linux. C'est une décision de spécialistes. Il n'a pas été refusé car le code n'était pas propre, etc. Il a été refusé car, toujours pour faire court, AppArmor sucks. Non qu'il ait des bugs, mais il n'est pas une bonne réponse aux problèmes de sécurité, il a trop de problèmes de conception.
> Dans ce cas, tu devrais te dépêcher de modifier l'article de Wikipedia
Sur Wikipedia, et je respecte ça n'en doute pas, toutes les voix comptes. Sur lkml, il n'y a que ceux qui ont fait leur preuve (c-à-d du code notamment) qui sont écouté.
Wikipedia n'est pas de l'avis de Linux, OK, faut faire avec, pas de problème. D'autant plus que l'article de Wikipedia donne un pointeur sur la discussion sur la lkml qu'il y a eu autour de AppArmor.
> Il y a encore beaucoup de discussions, sur la validité d'un choix de sécurité par les chemins ou par les inodes
Chez les spécialistes, je ne crois pas. La communauté de spécialiste autour de SeLinux est bien plus importante que pour AppArmor. Ce n'est pas un hazard.
Si ta question est "Pour l'utilisateur/administrateur final, vaut-il mieux AppArmor ou SeLinux ?", je n'ai pas de réponse.
Tout dépend d'un faisceau de chose.
AppArmor est plus simple, mais ne fait pas de flow control (ou c'est très limité). AppArmor ne peut pas être utilisé dans ce cas. Mais celui qui n'a pas besoin de ça s'en fout et peut utiliser AppArmor.
AppArmor ne peut pas faire de MLS. C'est utilisé par des adminstrations américaines. Donc pour ces dernières AppArmor ne peut être utilisé.
SeLinux est plus compliqué à mettre en oeuvre. J'utilise une distribution avec SeLinux. Que SeLinux soit compliqué, je m'en fous. Il est activité, je n'y touche pas. AppArmor ne m'apporterait rien et en plus il est moins "puissant" que SeLinux.
SeLinux commence son stade de simplification d'administration par l'utilisateur. C'est un début. A l'avenir il sera peut-être aussi simple de faire de chose simple avec SeLinux qu'avec AppArmor.
Mais, je crois définitivement que la conception d'AppArmor est moins bonne que SeLinux sur le plan sécurité. C'est mon avis et je ne suis pas un spécialiste. Mais j'ai pris la peine de m'informer (voir les liens que j'ai donné, que tu devrais aussi lire au-lieu de te limite à wikipedia).
> 1) arrêtons de nourrir les trolls basés sur l'imagination, fournissons de véritables éléments de comparaison
Voir les liens que j'ai donné.
> 2) arrêtons les délires sur les contre-projets de projets
???
> 3) >>> "On est rebelz ou on ne l'est pas, après tout." Arrêtons ces phrase sans intérêt dignes de jeunes de 13 ans.
Va lire les liens que j'ai donné au-lieu de faire un blocage sur une phrase.
# transcodage ?
Posté par IsNotGood . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à 3.
[^] # Re: Et l'avenir ?
Posté par IsNotGood . En réponse à la dépêche Sortie du noyau Linux 2.6.23. Évalué à 3.
> Du coup, l'utilisateur "personnel" (i.e. à la maison)
Lequel ?
Madame Michu ?
Pour un utilisateur, c'est toujours du boulot que de suivre les évolutions d'un projet dynamique. Ce n'est pas spécifique à Linux.
Madame Michu ne doit pas utiliser kernel.org, mais une distribution avec du support.
> un 2.6-quelquechose et ce quelque chose varie d'une distribution à l'autre.
Ce n'est pas un problème Linux. C'est le libre, c'est le choix des distributions.
Par exemple RHEL 5 (et ses clones) utilise un 2.6.18 (et sur toute la durée de vie de RHEL 5, c-à-d au moins 7 ans). Libre à toute distribution d'utiliser aussi le 2.6.18. Mais (et ce n'est pas un reproche) elles préfèrent prendre la dernière version lorsqu'une distribution est en gestation (exactement comme le fait Red Hat).
Il y a de bonnes raisons à ça et ce n'est pas que pour la frime. C'est aussi pour avoir le support de la communauté des développeurs Linux lors de la gestation de la distribution (les développeurs ont le nez dans la dernière version, pas dans les vieilles versions).
Il n'y a pas de solution unique au désagrément du modèle de développement de Linux. S'il y a une solution uniquement, c'est d'avoir les drivers en libre et upstream.
Mais voyons aussi ce qu'a apporté l'évolution rapide de Linux et qui répond à ton soucis. Aujourd'hui Linux marche "les doigts dans le nez". A l'époque de Linux 2.0, 2.2 et même le 2.4 (sauf peut-être les dernières versions de 2.4) beaucoup d'utilisateurs devaient recompiler le noyau, faire un checkout d'un CVS pour avoir un driver pour leur carte télé, etc...
Ce que je veux dire, c'est que remettre en cause la rapidité de développement de Linux (c-à-d aussi son modèle de développement), c'est aussi reppousser le moment où on a la solutions qui va bien (pour une carte télé qui marche "les doigts dans le nez", etc).
Aujourd'hui très peu recompile leur noyau, c'est aussi grace au modèle de développement de Linux. Certe, de façon indirect.
> De même, l'utilisateur "professionnel" (i.e. en entreprise et/ou développeur pour Linux) ne bénéficie plus de cette pérennité connue avec les noyaux <= 2.4 et le diagnostic est d'autant plus difficile.
Le professionnel veut une garantie de service (c'est-à-dire du support). Donc il prend (ou devrait prendre) une distribution professionelle (ou un clone de distribution professionnel s'il ne veut pas de support mais seulement la stabilité de l'api) et ne pas se poser de question et ne pas demander l'impossible à Linux (le Linux upstream). Linux ne peut pas évoluer vite (ce qui est hypra important sinon Linux est dépassé par les autres et ne répond pas aux attentes) et être figé.
Kernel.org n'a pas pour cible Madame Michu ni les professionnels.
> d'un certain nombre de logiciels/technos à côté (genre udev, dbus...).
Ces technos étaient en développement intensif. Ça devrait se calmer.
Notons que le libre est ouvert. Donc les technos en pleine gestation sont disponibles (ça a les inconvéniants de ses qualités).
> Bref, hors développeurs du noyau lui-même, il n'y a pas que des avantages.
Il faut penser à l'offre de GNU/Linux globalement. kernel.org n'est "que" le développement.
Si tu veux du stable (api), tu trouves.
Si tu veux du "chaud", tu trouves aussi.
Comme l'a faire remarquer le GeneralZod (c'était toi ?), beaucoup utilisent Fedora (c'est "chaud", c'est pour le développement, c'est pour la veille technologique, etc) ET RHEL ou ses clones (c'est "froid", ça ne bouge pas, c'est sans intérêt pour la veille technologique, etc). Il faut deux distributions (ou plus de façon plus générale) car il y a des objectifs d'utilisation incompatibles.
Linux (de kernel.org) ne peut pas répondre aux utilisateurs type Fedora et aux utilisateurs type RHEL (ou Debian stable ou Mandriva CS etc). C'est impossible.
# Quel scandale !
Posté par IsNotGood . En réponse au journal La dernière blague de free !. Évalué à 10.
Tout simplement scandaleux.
Déjà que free me donne rien pour avoir l'honneur d'héberger mes pages et ma base de donnée sur leurs putain de bécanes !
C'est décidé, je vais les héberger moi même mes pages.
Free peut toujours me souplier à genoux de rester, c'est décidé, je me casse.