wismerhill a écrit 2605 commentaires

En vrac

• Faire des lois discriminatoires pour favoriser les entreprises américaines
• Imposer leur vision de la justice aux pays qu'ils considèrent comme inférieures à eux (en gros tous à divers degrés)
• Bombarder un pays pour faire justice (lire: se venger) après un attentat
• Maintenir des dictatures dans les pays où ça les arranges

-1 parce que attaque enver les "maitres du monde"

C'est une idée intéressante, mais il faut encore que le package soit relocatable (heu, traduction?), il reste possible de forcer la relocation mais c'est risqué.

Chez moi quand je fais rpm -q urpmi --requires j'obtient
eject
webfetch
perl-DateManip >= 5.40
perl-gettext
rpmlib(VersionedDependencies) <= 3.0.3-1
rpmtools >= 4.2-4mdk
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
perl-base >= 5.601
bash
perl-base
Je ne vois rien de farfelu la-dedans.

Ah non, faut que ce soit /null alors.

Super la solution, et on se retrouve a devoir inventer des nom tarabiscotés pour que tous les fichiers aient un nom unique. C'est sur que ce sera plus clair.

Si tu n'a pas vu l'option compilé dans le noyau pour certaines parties, c'est probablement qu'ils dépendent de choses qui sont sélectionnées en module, du coup ils ne peuvent pas être dans le noyau car il ont besoin de ce module.
Sinon je crois qu'il y a certaines choses qui sont incompatibles et il n'est peut-être pas possible de compiler la totalité du code dans un noyau monolithique.

PS: n'oublie pas la compression, le noyau est compressé en bz2 (make bzImage) et, sur la mandrake et probablement d'autres, les modules sont compressés en gzip, donc une fopis décompressé en mémoire ça prend beaucoup plus de place.
PPS: non tout ne se retrouve pas en mémoire, exemple chez moi il y a 44 modules en mémoire (ça doit varier de quelques uns quivant l'utilisation) et il y en a 335 de compilés, et encore, c'est un noyau que j'ai compilé moi-même, dans ceux fourni en standard avex ma distrib il y en a 1095.

urpmi sur une redhat?
;-)

C'est gcc3 le plus important dans le tas, tous les programmes ont été recompilés avec celui-là, et la partie c++ n'est pas compatible avec les précédents, donc si tu as des programmes que tu as compilé toi-même il faudra recompiler.

Entre beta je ne sais pas. Mais à partir d'une version précédente tu peut faire une mise à jour. La mienne est actuelement une 8.2, mise à jour de la 8.1, mise à jour de la 8.0 mise à jour de la 7.2 (par contre la 8.2 ne supporte pas la mise à jour directement depuis la 7.2) et on peut supposer que je pourrai mettre à jour cette 8.2 en 9.0 (enfin j'espère qu'il n'y aura pas des problèmes avec KDE, j'ai complètement remplacé le 2 par le 3).

Il y a une image de disquette qui permet de faire une installation à partir du réseau, mais je ne sais pas si ça marche via internet.
Je ne comprend pas bien ta dernière question.

Non, il suffit de laisser l'administrateur... administrer les machines et ne pas donner aux utilisteurs les mots de passe root mais juste des compte... utilisateur. Ils n'auront pas besoin de s'occuper d'installer des programmes, l'admin se charge d'installer sur les machines les programmes dont ils ont besoin pour travailler.

Formidable, avant il y avait ceux qui se plaignaient que mdk ne testait pas assez ses distrib, maintenant qu'ils font plus de beta il y en a encore pour se plaindre. En quoi ça te dérange, on est venu chez toi te forcer à la télécharger? De quoi tu te plaint?

Prenons l'exemple encore une fois de BeOS : l'installation d'une librairie (dans les rares cas ou c'est nécessaire) consiste à déposer le fichier dans le raccourci qui ira le ranger la ou il faut.
Et un an après, quand tu as installé et désintallé plein de programmes, tu as plein de bibliothèques dans plusieurs versions différentes et tu sais pas lesquelles sont nécessaires aux programmes encore installés, donc tu laisse tout et ça encombre, pire ça peut même faire des incompatibilités.
En clair, c'est le modèle windows: on installe tout ce qu'on veut et quand on s'y retrouve plus on formate et on réinstalle.

Oui, il peut le faire, à condition de bien dire qu'il ne s'agit pas de la gpl mais d'une version modifiée.

J'avais acheté le 1 et le 2, mais le 3 je ne l'ai pas encore vu en belgique...

Donc Debian n'est pas du tout dans l'esprit du libre, puisqu'ils ne font une distrib stable que tous les siècles.

[-1]

1. Oui c'est de la sélection édition que je parlais, avant ça fonctionnait juste comme des paragraphes et on pouvait sélectionner que par lignes. Maintenant on peut sélectionner/copier/coller des blocs de taille quelconque. En plus le dialogue pour les tableaux s'est amélioré.

2. Ce qui est prévu pour la 1.3 c'est que le guii soit fonctionnel, à partir de là on pourra utiliser tous les toolkit pour lesquels l'ensemble complet de l'interface aura été convertie. Xforms sera disponible et apparemment qt aussi, pour gnome il semble que ça en est trop loin et ça avance très lentement. Donc utilisateur de LyX sous Gnome votre contribution est la bienvenue!

Ça fonctionne très bien avec xforms 0.88 (enfin, pour autant qui'on puisse dire que xforms fonctionne bien).

wysiwwwyts (what you see is what we want you to see)

Je peut essayer aussi: wysiwywgiyhiypc (what you see is what you would get if you had installed your printer correctly).
Et un autre: wyswnbstswbae (what you see will never be seen the same way by anuyone else).
Encore un: ygwystwha (you got what you see? that won't happen again).
C'est marrant ce jeu ;-)

Voici une remarque de Waldo Bastian (vue sur http://www.pclinuxonline.com(...)):
"Anyone who uses Konqueror for secure transactions on the Internet is strongly urged to upgrade. Users of Internet Explorer, which suffers from the same problem but which does not yet have a fix available, are also encouraged to switch to KDE 3.0.3."

La première beta de KDE 3.1 ne devrais pas tarder, d'après le release plan (http://developer.kde.org/development-versions/kde-3.1-release-plan.(...)) elle doit être annoncée aujourd'hui.

Le nom des package n'est pas un problème, il suffit de bien définir ce que fourni le package ("provides" dans rpm, c'est lui que je connais).
Dans ton exemple, tu crée disons un package qui s'appelle mesa et tu met dans sa liste de provides libgl mesa mesagl, ainsi si un autre package s'attend à trouver mesa ça parche, si un autre veut libgl ça marche aussi.
Le problème c'est si ces définitions se multiplient (faut penser à tout), ou pire encore s'il y a des recouvrements (tel package fourni bien cette fonctionnalité, mais ce n'est en fait pas celle attendue par le package, elle a juste le même nom), d'où la nécessité d'une standardisation à ce niveau-là.

Et suis-je le seul à trouver que *Office à un moins beau rendu (sur écran comme sur papier) que LaTeX ?

<avis partialité=100%>
De toute façon rien n'égale le rendu, ni la flexibilité de LaTeX ;-) ;-)
</avis>

Et sous Linux on fait comment?

Extrait des script d'un package pris au hasard
if [ "$1" = "0" -a -x /usr/bin/update-menus ]; then /usr/bin/update-menus || true ; fi
Bien sue que c'est fait dans les script du package. D'ailleur quand tu fait tes package rpm sur une mandrake il te suffit de mettre dans ton specfile

%post
%{update_menus}

%postun
%{clean_menus}

et c'est bon, ils ont prévu des macro pour encore simplifier ça.