> Parceque bon tu critiques un truc que visiblement t'as jamais essaye
Déjà, j'ai essayé une Debian. D'accord c'était il y a longtemps (à la sortie de la woody et la 1.3 dont j'ai oublié le nom).
Où je critique Debian ici ? Nul part. Ce que je dis, et c'est mon avis, c'est qu'il est "bête" (à mon avis) de faire toute la configuration en même temps que l'installation et que donc il est "bête" (à mon avis) de faire croire que debian ne peut pas changer d'installeur à cause d'indépendances avec des outils des configurations.
> tu racontes (comme d;hab) que des conneries HS
La réponse de Vincent Haverlant ci-dessous est un avis intéressant et très respectable.
PS : Désolé pour le nom de distribution que j'ai laissé trainé.
Posté par mat1 .
En réponse au journal x.org.
Évalué à -1.
Le switch vers X.org *semble* définitif.
Une copie d'un mail (sans les noms de distributions évidement) du 16 Février 2004 : XFree86 -- new license
------ -. ------ ------@------.---
Mon, 16 Feb 2004 01:03:34 -0500 (EST)
On Mon, 16 Feb 2004, Donnie Berkholz wrote:
>What are you guys doing about the new license? Still planning to ship
>4.4.0, or the last stuff before the license change, or some other
>alternative?
>
>We've been putting out the snapshots, but I might hold off on RC3
>pending some sort of consensus on the licensing.
Hi Donnie,
We currently have no plans to ship XFree86 4.4.0 in the future.
------ is a strong supporter of open source software and
technologies, and the new XFree86 license seems to be intended to
restricting existing freedom for no real world technical or other
gains. At least no gains that are beneficial to the community.
Richard Stallman of the Free Software Foundation has expressed
his concerns publically about the new XFree86 license and it's
incompatibility with the GPL. Many others in the community
object strongly to the new license as well.
Branden Robinson of the ------ project has put together a list of
license related issues contained in XFree86's source tree, and
efforts are underway to remove code which is considered to be
non-open source, or under too restrictive of license terms.
Our current plan, is to use the freedesktop.org xlibs for the
client side libraries. For the clients, utilities, X server, and
other bits, we have not yet made a 100% solid decision, however
a couple of alternatives are being explored. The details are
not yet completely decided, however one thing that is decided, is
that the XFree86 license version 1.1 is unacceptable.
X11 has sorely lacked such an open and collaborative development
environment for a very long time. It's now time for the open
source community to unite and work together on solving this
problem together, and give X11 permanently back to the community!
I very much look forward to working together in collaboration
with yourself, the ------ project, ------, ------, ------, X.org
foundation, the other ------s, and any/all other interested parties
on a true open source solution for the needs of X11 users and
developers.
Posté par mat1 .
En réponse au journal x.org.
Évalué à -2.
changelog du paquet [...] : * mer mar 10 2004 ------------------------------------
0.0.6.6-0.0.2004_03_09.0
- Initial xorg-x11 package, forked from the XFree86-4.3.0-63 package
- Package name chosen as xorg-x11 due to lack of official upstream package
name at this point. Name may change in the future, so people should not
hard code any dependancies on it. Version and Release fields future proofed
for similar reasons, as we do not know what upstream version will be.
La XFree86-4.3.0-63 etait la dernière version. Le distributeur semble clairement abandonner XFree86.
Ça mérite presque un news. Faudrait fouiller les mailing-list pour connaitre les tenants et aboutissants. Mais sans citer, le distributeur .... c'est sans intérêt.
> va tester Debian (apt & debconf) puis compare avec Fedora :)
Le propos n'est pas là. C'est pas une question de "j'en ai une plus grosse que la tienne".
C'est pour clarifier.
Est-il nécessaire de configurer bind lors de l'installation ? Non.
L'installeur n'est pas là pour configurer tout le système. Il fait un minimum de configuration et le reste tu le fais lorsque ton SE est installé. C'est beaucoup plus confortable.
L'installeur utilise un shell. Es-ce que l'objectif d'un installeur est d'être un shell ? Non. Idem pour les outils de configuration.
On est pas sortie avec ça. Tout est configuration alors... Il faut un minimum de configuration pour installer. C'est évident. Mais le rôle d'un installeur n'est pas la configuration. Je ne vais pas lancer mon installeur pour configurer bind.
Sur la distribution que j'utilise (et que je ne dois pas nommer), après l'installation je peux faire "(outils de gestion de paquet de ma distribution que je tais afin de ne pas être remarqué) --erase (paquet qui fait l'installation et que je ne nomme pas pour ne pas froisser la suceptibilité de certains)".
> on s'en fout que lilo soit ou pas dans la fedora^W^A
Oui.
Désolé mille fois.
J'aurai du dire, une distribution (que je ne citerai pas) utilise Grub depuis un moment, etc...
Le propos est de dire que Grub est utilisé depuis longtemps. Je l'utilise depuis la version 6.2 (d'une distribution que je ne dois pas citer). Et que malgrés celà lilo reste toujours d'actualité car il y a des caractérisques uniques.
PS : Je laisse les numéros de version car j'ai pas envis de perdre mon temps à chercher la date de sortie d'une distribution que je ne dois pas nommer car les gens sont trop cons pour comprendre qu'on peut parler une distribe X sans vouloir la "mort" de la distribution Y.
Et le flou c'est tellement érotique...
PS2 : fais toi un filtre sur ton réseau qui vire tout les occurences de ^A et ^A. Tu peux en profiter pour remplacer ces noms honteux par ta distributions préférée si ça te flatte.
Le configuration et l'installation c'est pas vraiment la même chose. Par exemple anaconda est uniquement utilisé à l'installation. Mais il est vrai qu'anaconda fait un minimum de configuration (partitionnement, selection de paquet, mot de passe root, langue, et c'est pratiquement tout). Par contre il ne fera pas le configuration d'apache, ftp, l'ajout de compte, etc...
Chez RedHat/Fedora, la tendance est de virer un maximum de choses d'anaconda et de les mettre dans firstboot (un programme lancé au premier boot automatiquement et qui peut être relancé si nécessaire (faire "chkconfig --add firstboot" puis rebooter). L'autre intérêt est que firstboot peut utilisé des composants des outils de configuration (system-config* anciennement redhat-config*).
Ça permet aussi d'automatiser la configuration de machine et d'avoir un firstboot que ne demande que la création d'un compte utilisateur par exemple.
Grub est par défaut dans RedHat depuis la 7.2 et lilo a été viré pour la 8.0 . Bizarrement lilo a fait sont retour dans Fedora. J'ai oublié pour quelle raison (c'est lié au raid) mais lilo a des fonctionnalités que n'a pas grub. Néanmoins le team Fedora souligne que lilo sera viré (à nouveau) lorsque grub aura les fonctionnalités manquantes (ça ne devrait pas être long).
La compatibilité c'est intéressant pour quelque chose de complexe (ça t'évite de perdre du temps à apprendre un nouveau truc compliqué) ou lorsque que c'est très utilisé.
L'installeur est simple et uniquement utilisé à l'installation. Donc la compatibilité n'est pas un critère très important.
> Le problème est sur les différentes architectures supportée.
Anaconda tourne sur 7 architectures. De plus, si le mode graphique n'est pas disponible il passe en mode texte (on peut aussi forcer le mode texte).
Mais bon, le problème n'est pas que ce soit graphique ou non mais que ce soit simple à l'installation. Le pro aura tout loisir de paufiner après.
Puis si ça évite la multiplaction des installeurs, c'est un plus. Car finalement tous les installeurs font grosso-modo la même chose. Le cahier des chages pour l'installeur est pratiquement le même pour Fedora/Mdk/Gentoo/Debian/Slack/...
> gnome 2 et surement KDE 3 doit les stocker en utf8 par convention
Ça n'a pas vraiment de sens.
C'est la librairie C qui prend en charge utf-8.
Démonstration avec touch et ls
$ echo $LANG
fr_FR.UTF-8
$ touch êççÇd«ßðđŋ
$ ls
êççÇd«ßðđŋ
$ env LANG=fr_FR.iso88591 ls
�?��?��?�êçç�?d«�?ð�?�?
Il y a une relation directe en UTF-32 et UTF-8. Si UTF-32 ne supporte pas un truc alors UTF-8 ne le support pas non plus.
> résultat l'UTF-8 bugge
Comment peut-on dire qu'un standard est buggé ? Peut-être parles tu d'une police qui mappe deux codes UTF vers le même glyph. C'est possible et ce n'est pas un bug ! C'est utilisé pour bouffé moins de place disque. Il peut y avoir des polices qui ont des glyph distincts pour le chinois et le japonais. Ce n'est pas un problème d'UTF-8 et ce n'est pas un bug.
Lorsque le 2.6.0 est sorti il n'y avait pas "tout" dedans. Entre autre car certains préfèrent éviter le "bordel" (créatif) d'une branche de développement. Ce qui manquait au 2.6.0 peu maintenant être ajouté au pas de charge car le noyau est assez stable. S'il y a plusieurs releases, c'est pour bien séparer j'ajoute de fonctionnalité et isoler les problèmes s'il y en a. De plus, tous les développeurs sont concentrés sur la 2.6 . Quand il y aura la 2.7, ça va se calmer.
Tant que les releases ne sont pas des bugfix de "grosses conneries", je n'y vois aucun problème.
> Ais-je le droit de copier la Powerpack d'un copain ?
non. Par contre le copain peut te passer sa Powerpack avec les licences. C-à-d qu'une fois que tu l'as, il ne l'utilise plus.
> Ais-je le droit de la diffuser sur bittorrent ?
non.
Absolument d'accord. Il y en a qui "résiste" par instinct "anti-microsoft" et d'autres pour des raisons de performance.
NB : quand je disait "même si ce n'est pas encore parfais" c'est parcequ'il y a quelques manque dans la libc (peut-être déjà comblé) et que certaines applis ne supportent pas encore UTF-8.
> Est-on en bonne voix pour n'avoir que du UTF-x partout et ne plus utiliser l'ASCII ?
Depuis la RH8.0, par défaut c'est UTF-8.
> Ou certaines parties vont être gardées en ASCII (genre le file system...) ?
Le file system n'a pas de charset (rien et même pas ASCII). Un fichier est toujours binaire (sauf pour la libc pour la bufferisation et autre getline()). Un nom de fichier est un char * (plus interdiction d'utiliser le code qui représente '/' (en ascii)).
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à 2.
Les deux.
> Parceque bon tu critiques un truc que visiblement t'as jamais essaye
Déjà, j'ai essayé une Debian. D'accord c'était il y a longtemps (à la sortie de la woody et la 1.3 dont j'ai oublié le nom).
Où je critique Debian ici ? Nul part. Ce que je dis, et c'est mon avis, c'est qu'il est "bête" (à mon avis) de faire toute la configuration en même temps que l'installation et que donc il est "bête" (à mon avis) de faire croire que debian ne peut pas changer d'installeur à cause d'indépendances avec des outils des configurations.
> tu racontes (comme d;hab) que des conneries HS
La réponse de Vincent Haverlant ci-dessous est un avis intéressant et très respectable.
PS : Désolé pour le nom de distribution que j'ai laissé trainé.
# Re: x.org
Posté par mat1 . En réponse au journal x.org. Évalué à -1.
Une copie d'un mail (sans les noms de distributions évidement) du 16 Février 2004 :
XFree86 -- new license
------ -. ------ ------@------.---
Mon, 16 Feb 2004 01:03:34 -0500 (EST)
On Mon, 16 Feb 2004, Donnie Berkholz wrote:
>What are you guys doing about the new license? Still planning to ship
>4.4.0, or the last stuff before the license change, or some other
>alternative?
>
>We've been putting out the snapshots, but I might hold off on RC3
>pending some sort of consensus on the licensing.
Hi Donnie,
We currently have no plans to ship XFree86 4.4.0 in the future.
------ is a strong supporter of open source software and
technologies, and the new XFree86 license seems to be intended to
restricting existing freedom for no real world technical or other
gains. At least no gains that are beneficial to the community.
Richard Stallman of the Free Software Foundation has expressed
his concerns publically about the new XFree86 license and it's
incompatibility with the GPL. Many others in the community
object strongly to the new license as well.
Branden Robinson of the ------ project has put together a list of
license related issues contained in XFree86's source tree, and
efforts are underway to remove code which is considered to be
non-open source, or under too restrictive of license terms.
Our current plan, is to use the freedesktop.org xlibs for the
client side libraries. For the clients, utilities, X server, and
other bits, we have not yet made a 100% solid decision, however
a couple of alternatives are being explored. The details are
not yet completely decided, however one thing that is decided, is
that the XFree86 license version 1.1 is unacceptable.
X11 has sorely lacked such an open and collaborative development
environment for a very long time. It's now time for the open
source community to unite and work together on solving this
problem together, and give X11 permanently back to the community!
I very much look forward to working together in collaboration
with yourself, the ------ project, ------, ------, ------, X.org
foundation, the other ------s, and any/all other interested parties
on a true open source solution for the needs of X11 users and
developers.
Take care!
TTYL
--
------ -. ------ ftp://people.------.com/------(...)
OS Systems Engineer - XFree86 maintainer - ------
[^] # Re: x.org
Posté par mat1 . En réponse au journal x.org. Évalué à -3.
C'est pas à mon age que ça va changer.
# Re: x.org
Posté par mat1 . En réponse au journal x.org. Évalué à -2.
* mer mar 10 2004 ------------------------------------
0.0.6.6-0.0.2004_03_09.0
- Initial xorg-x11 package, forked from the XFree86-4.3.0-63 package
- Package name chosen as xorg-x11 due to lack of official upstream package
name at this point. Name may change in the future, so people should not
hard code any dependancies on it. Version and Release fields future proofed
for similar reasons, as we do not know what upstream version will be.
La XFree86-4.3.0-63 etait la dernière version. Le distributeur semble clairement abandonner XFree86.
Ça mérite presque un news. Faudrait fouiller les mailing-list pour connaitre les tenants et aboutissants. Mais sans citer, le distributeur .... c'est sans intérêt.
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à 1.
Le propos n'est pas là. C'est pas une question de "j'en ai une plus grosse que la tienne".
C'est pour clarifier.
Est-il nécessaire de configurer bind lors de l'installation ? Non.
L'installeur n'est pas là pour configurer tout le système. Il fait un minimum de configuration et le reste tu le fais lorsque ton SE est installé. C'est beaucoup plus confortable.
L'installeur utilise un shell. Es-ce que l'objectif d'un installeur est d'être un shell ? Non. Idem pour les outils de configuration.
[^] # Re: Debian de plus en plus simple.
Posté par mat1 . En réponse au journal Debian de plus en plus simple.. Évalué à 0.
> Comme d'hab, n'importe quoi.
Je te laisse te renseigner plus tout seul. Je vais pas te tenir la main.
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à 1.
T'es fort toi. Mais houplacrash reste le plus fort :
http://linuxfr.org/~mat1/9545.html(...)
Je suis tombé dans son piège.
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à -1.
Sur la distribution que j'utilise (et que je ne dois pas nommer), après l'installation je peux faire "(outils de gestion de paquet de ma distribution que je tais afin de ne pas être remarqué) --erase (paquet qui fait l'installation et que je ne nomme pas pour ne pas froisser la suceptibilité de certains)".
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à -1.
Oui.
Désolé mille fois.
J'aurai du dire, une distribution (que je ne citerai pas) utilise Grub depuis un moment, etc...
Le propos est de dire que Grub est utilisé depuis longtemps. Je l'utilise depuis la version 6.2 (d'une distribution que je ne dois pas citer). Et que malgrés celà lilo reste toujours d'actualité car il y a des caractérisques uniques.
PS : Je laisse les numéros de version car j'ai pas envis de perdre mon temps à chercher la date de sortie d'une distribution que je ne dois pas nommer car les gens sont trop cons pour comprendre qu'on peut parler une distribe X sans vouloir la "mort" de la distribution Y.
Et le flou c'est tellement érotique...
PS2 : fais toi un filtre sur ton réseau qui vire tout les occurences de ^A et ^A. Tu peux en profiter pour remplacer ces noms honteux par ta distributions préférée si ça te flatte.
[^] # Re: Debian de plus en plus simple.
Posté par mat1 . En réponse au journal Debian de plus en plus simple.. Évalué à 1.
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à 1.
Anaconda pour debian (progeny) :
http://platform.progeny.com/anaconda/(...)
Pour info, anaconda peut aussi marché en mode texte.
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à 2.
Ce n'est pas couvert par la LSB et ça ne le sera pas.
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à 1.
Chez RedHat/Fedora, la tendance est de virer un maximum de choses d'anaconda et de les mettre dans firstboot (un programme lancé au premier boot automatiquement et qui peut être relancé si nécessaire (faire "chkconfig --add firstboot" puis rebooter). L'autre intérêt est que firstboot peut utilisé des composants des outils de configuration (system-config* anciennement redhat-config*).
Ça permet aussi d'automatiser la configuration de machine et d'avoir un firstboot que ne demande que la création d'un compte utilisateur par exemple.
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à -5.
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à 2.
Avec un 2.6 (peut-être aussi pour le 2.4) un "make install" fait un /sbin/installkernel et /boot/grub/grub.conf est mis à jours.
[^] # Re: 3ème et dernière bêta de l'installateur Debian Sarge
Posté par mat1 . En réponse à la dépêche 3ème et dernière bêta de l'installateur Debian Sarge. Évalué à 2.
[^] # Re: Debian de plus en plus simple.
Posté par mat1 . En réponse au journal Debian de plus en plus simple.. Évalué à 1.
http://fedora.redhat.com/projects/config-tools/(...)
# Kudzu - for hardware detection
cvs :
export CVSROOT=:pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS
cvs -z3 login
cvs -z3 co kudzu
[^] # Re: Debian de plus en plus simple.
Posté par mat1 . En réponse au journal Debian de plus en plus simple.. Évalué à 1.
L'installeur est simple et uniquement utilisé à l'installation. Donc la compatibilité n'est pas un critère très important.
[^] # Re: Debian de plus en plus simple.
Posté par mat1 . En réponse au journal Debian de plus en plus simple.. Évalué à 2.
Anaconda tourne sur 7 architectures. De plus, si le mode graphique n'est pas disponible il passe en mode texte (on peut aussi forcer le mode texte).
Mais bon, le problème n'est pas que ce soit graphique ou non mais que ce soit simple à l'installation. Le pro aura tout loisir de paufiner après.
Puis si ça évite la multiplaction des installeurs, c'est un plus. Car finalement tous les installeurs font grosso-modo la même chose. Le cahier des chages pour l'installeur est pratiquement le même pour Fedora/Mdk/Gentoo/Debian/Slack/...
[^] # Re: Sortie du noyau 2.6.4
Posté par mat1 . En réponse à la dépêche Sortie du noyau 2.6.4. Évalué à 1.
Ça n'a pas vraiment de sens.
C'est la librairie C qui prend en charge utf-8.
Démonstration avec touch et ls
$ echo $LANG
fr_FR.UTF-8
$ touch êççÇd«ßðđŋ
$ ls
êççÇd«ßðđŋ
$ env LANG=fr_FR.iso88591 ls
�?��?��?�êçç�?d«�?ð�?�?
[^] # Re: Sortie du noyau 2.6.4
Posté par mat1 . En réponse à la dépêche Sortie du noyau 2.6.4. Évalué à 1.
> résultat l'UTF-8 bugge
Comment peut-on dire qu'un standard est buggé ? Peut-être parles tu d'une police qui mappe deux codes UTF vers le même glyph. C'est possible et ce n'est pas un bug ! C'est utilisé pour bouffé moins de place disque. Il peut y avoir des polices qui ont des glyph distincts pour le chinois et le japonais. Ce n'est pas un problème d'UTF-8 et ce n'est pas un bug.
[^] # Re: Sortie du noyau 2.6.4
Posté par mat1 . En réponse à la dépêche Sortie du noyau 2.6.4. Évalué à 2.
Tant que les releases ne sont pas des bugfix de "grosses conneries", je n'y vois aucun problème.
[^] # Re: Sortie du noyau 2.6.4
Posté par mat1 . En réponse à la dépêche Sortie du noyau 2.6.4. Évalué à -1.
Disons que c'est aussi un truc "hype". Ça permet de frimer quoi.
[^] # Re: Ze question
Posté par mat1 . En réponse à la dépêche Mandrake Linux 10.0 Community disponible au téléchargement. Évalué à 0.
non. Par contre le copain peut te passer sa Powerpack avec les licences. C-à-d qu'une fois que tu l'as, il ne l'utilise plus.
> Ais-je le droit de la diffuser sur bittorrent ?
non.
[^] # Re: Sortie du noyau 2.6.4
Posté par mat1 . En réponse à la dépêche Sortie du noyau 2.6.4. Évalué à 0.
Absolument d'accord. Il y en a qui "résiste" par instinct "anti-microsoft" et d'autres pour des raisons de performance.
NB : quand je disait "même si ce n'est pas encore parfais" c'est parcequ'il y a quelques manque dans la libc (peut-être déjà comblé) et que certaines applis ne supportent pas encore UTF-8.
> Est-on en bonne voix pour n'avoir que du UTF-x partout et ne plus utiliser l'ASCII ?
Depuis la RH8.0, par défaut c'est UTF-8.
> Ou certaines parties vont être gardées en ASCII (genre le file system...) ?
Le file system n'a pas de charset (rien et même pas ASCII). Un fichier est toujours binaire (sauf pour la libc pour la bufferisation et autre getline()). Un nom de fichier est un char * (plus interdiction d'utiliser le code qui représente '/' (en ascii)).