Blackknight a écrit 1237 commentaires

Juste pour dire, la carte d'identité est gratuite.

En sortant du chapeau des jolis numéros, et des mots bien compliqués ? Voilà en plus que l'on se retrouve soit disant accusé si l'on réagit ?
En plus, je ne connais pas trop l'aspect légal du verbe to flame. AMHA, il a autant de valeur que 3L33TZ, Warez et autres warlords...

Le SGML n'est pas un truc completement stupide et mal foutu.
D'ailleurs, je pense qu'il est utile de rappeler que DocBook, un langage à balises fortement utilisé dans la documentation des logiciels libres, est au départ une DTD SGML, il existe aujourd'hui une version XML de la chose. Comme tout document XML, il n'est pas forcément valide pour SGML (voir au-dessus les balises fermées). De plus, SGML a une existence plus longue qu'XML qui n'a d'égal que sa compléxité et ses possibilités. Enfin, pour mémoire, XML a été écrit pour simplifier l'échange de données entre systèmes mais surtout pour simplifier SGML et le rendre plus accessible.

????

Tu favorises l'accessibilité pas la visiblité ni l'universalité et ce sont ces deux derniers points qui sont importants. Permettre l'accès à l'information par le plus grand nombre se fait certes par l'établissement de standards mais les gens sur le terrain doivent suivre.

Ne pas se préoccuper des standards ne veut pas dire qu'on ne jure que par IE et les "$" de "M$". Il y a des tas de gens qui s'assurent que leurs sites sont lisibles sous Netscape 4 (par exemple), sans pour autant qu'ils soient conformes aux standards du W3C.

Bien d'accord, ne serait-ce que pour les sites persos qui n'intéressent généralement que les proches du designer. Et bien, le designer en question, que va-t-il faire ? Faire du CSS2, du XHTML, des PNG (mal gérés sous IE mais aussi sous NS4) ? Et quand les fameux proches diront : "C'est bien d'avoir fait un site mais je peux pas voir les photos du p'tit ?", il répond quoi le designer ? "Passe à Mozilla" ? "Change ton Windows pour un Linux" ?
Tout ça, c'est du combat d'arrière-garde et/ou d'informaticiens. N'oublions quand même pas que le site on ne le fait pas pour nous (normalement, on connait déjà les infos qu'il y a dedans), on le fait pour les autres. Alors à moins de connaître par avance les navigateurs utilisés par toutes les personnes qui liront le site, il faut avant tout vérifier que le site est lisible par tous les intéressés.
Ceci dit, il est intéressant (voire obligatoire quand on a les connaissances) de réussir à faire un site conforme et lisible par tous (ceux qui me diront que c'est impossible non certainement jamais essayé).
Je sens que les trolls vont pleuvoir mais faire du xhtml (même si c'est une norme) et toutes les technologies de pointe en montrant du doigt ceux qui sont à la traine, c'est de l'élitisme technologique et je suis désolé mais pour de l'accès à la culture et l'information, c'est MAL (TM). Petite comparaison : Je voudrais bien voir la tête de ceux qui prônent la modernisation de l'informatique si demain, une grande et bonne chaîne de télé (désolé, je n'ai pas encore de nom susceptible de correspondre à cette définition) ne diffusait ses émissions que pour écrans plasma en 21/8 (format débile, je vous l'accorde ... de piano) à 5000 euros.

Le but des sites publics n'est pas de faire pression sur des entreprises, mais d'être lisibles par le plus de citoyens possibles. Evidemment, si on peut faire les deux à la fois, tant mieux, mais dans le cas contraire il faut savoir se fixer des priorités.
D'accord aussi vu ce que je viens d'écrire.

Comme indiqué sur le Cederqvist (voir sur le site de cvs http://www.cvshome.org/(...) ) page 138, annexe C, paragraphe 7.2 "Keeping a checked out copy".
Dans cet exemple, on utilise le fichier loginfo pour faire un cvs update sur le serveur à chaque commit. Ainsi, tu travailles sur ta copie e tu l'as fait tourner avec une BDD de test et les CGI qui vont bien et quand tu as fini et testé à fond ;-), tu commit et le site Web est automatiquement mis à jour. En règle générale avec un petit peu de code en shell, perl ou autre, tu peux réussir à faire faire à peu près ce que tu veux à CVS. Par contre, il faut lire tout le passage sur les fichiers d'admnistration mais ça se fait et c'est pas trop compliqué.

PS: tu peux aussi taper info cvs pour avoir le Cederqvist directement sur ta bécane. Perso, je préfère la version PS.

T'as aussi prévenu les gens de Linuxgraphic.org ?

Le couple dump/restore possède un très, très gros avantage sur les tar, cpio et rsync : La gestion des fichiers spéciaux.
Et oui, tar, cpio et rsync servent à copier des fichiers normaux (répertoires inclus). Ils servent à la sauvegarde de fichiers.
Dump permet quant à lui la sauvegarde de systèmes de fichiers (filesystem pour les Anglophiles).
En conclusion, tous n'ont pas la même utilité. On utilisera tar et consorts pour la sauvegarde des données utilisateur ou applis et on utilisera le couple dump/restore pour la sauvegarde du système complet.

De toutes façons, il n'y a jamais de bon benchmark. Un benchmark est à faire en fonction de l'application visée. En clair, pour faire un site comme Linuxfr, inutile de se demander si c'est .Net, J2EE ou LAMP qui a été benchmarké par une sombre boîte de consulting comme vainqueur toute catégorie, LAMP est la solution pour un tel site. Par contre, sur un site d'e-commerce, il y a peut-être match (et même surement) : dans ce cas, on développe trois proto et là, on peut faire du benchmarking et choisir la technologie pour la suite du projet. Enfin, il faut bien réfléchir dès le départ aux évolutions possibles de l'application car cela peut conditionner aussi la techno (On peut pas franchement dire que PHP soit super souple pour les évolutions mais c'est un avis perso).

Pour finir, c'est la même chose pour les OS, le choix d'un OS est toujours conditionné par ce que l'on veut en faire.

PS: Pour parler de MySQL, le plus beau benchmark que j'ai jamais vu est chez eux, à la limite du trollissime (http://www.mysql.com/information/benchmarks.html(...) ). Fallait quand même oser comparer DB2 et Oracle à MySQL et surtout en sortir les résultats qu'ils ont sortis.

D'autre part, de nombreux clients ne peuvent changer de banques car ils sont bloqués par contrat : typiquement en cas de prêt bancaire, on peut pas trop changer de banque (mon cas par exemple).
Il y a toujours le rachat de prêt bancaire qui te permet de changer de banque. Il faut savoir qu'aucun contrat ne peut pas être dénoncé, en clair, le contrat sans fin est impossible.

Heu, planète Linux, ce sont bien les CD livrés avec 15 pages de magazine ? Du coup, faut savoir ce que l'on veut : un magazine avec un CD ou des CDs avec un "magazine".

Les voyageurs du temps aussi c'était super et assez tordu qui plus est. Ne parlons même pas d'opération Stealth.
Tout ça, c'était vraiment que du bon ! En plus, ça demandait un minimum de réflexion.

La non-lisibilité, il n'y a pas que sous IE. Depuis le nouveau site, Netscape 4.79 peut plus le lire non plus. C'est ça l'accès à la technologie à double vitesse, si t'as un vieux PC sur lequel tu peux pas faire tourner les derniers soft de la mort qui tue, t'es foutu. Le XHTML, c'est bien mais avec un navigateur récent.

PS: Inutile de lancer une série sur les meilleurs browsers du monde, c'est du déjà vu.

Et avec l'utilisation d'Amanda, tes backups journaliers font quelle taille ? Parce qu'il me semble que le découpage avec le taux de changement permet d'économiser une bonne partie d'espace par rapport à un backup complet.

Pour les filesystems, dump et restore sont les incontournables mais bonjour la place disque puisque les fichiers résultants sont de la taille du filesystem sauvegardé => quand on sauvegarde sur bande, il faut généralement un lecteur de bonne capacité compte tenu de la taille des disques actuels.
Pour les fichiers seuls, il y a bien sûr tar et cpio mais j'aurais tendance à préférer pax pour son côté Posix.
Et sinon, je n'ai pas essayé mais Amanda me semble quand même super sympa.
Enfin, tout ça avec un petit disque en RAID 10 ou mieux 5 (logiciel avec vinum sur FreeBSD ou Linux volume manager sous Linux bien sûr pour les pauvres comme moi), ça permet quand même de se sortir de pas mal d'impasses.
Ceci dit, jetes quand même un oeil sur le lien sur l'ESA d'O'Reilly, ça vaut la peine d'être lu, ne serait-ce que pour la culture personnelle.

Il n'y a rien de bien nouveau dans le fait que BitKeeper est non libre. Que Debian s'en offusque seulement maintenant est assez bizarre. En effet, le choix de BitKeeper date déjà de quelques semaines (mois ?). Je trouve d'ailleurs cela assez dommage que l'équipe de Linus en soit arrivé à utiliser ce soft. Si ça continue, ils utiliseront peut-être ClearCase !!
Le projet FreeBSD est aussi en train de se poser la question de l'utilisation de CVS pour la gestion des sources de l'OS. Par contre, le remplacant pourrait être Perforce qui lui reste libre (me semble-t-il).

En dehors de cela, BitKeeper n'est pas un logiciel de révision mais un logiciel de gestion de configuration (car on peut y gérer autre chose que du source ou que du document texte).

Heu ??!! Comme Isabelle ??

Et l'intérêt de la news du coup ??
Parce que sinon, je connais un super aspirateur Web en Java qui sera fini un jour et qui ce jour-là sera en download !!

Bon, je vais essayer de ne pas troller ;-) donc exit les problèmes de licences.
Commençons par le noyau :
- la configuration avant compilation se fait dans un simple fichier texte et est assez simple
- il est relativement monolithique et sa taille est donc largement supérieure à un noyau Linux. Toutefois, cette différence tend à disparaître et on observe de plus en plus de gens configurer un noyau léger et utiliser le kldload (équivalent au insmod Linux)

Le système à proprement parler:
- Initialisation à la BSD (jusque là rien d'anormal) c'est-à-dire que l'on ne trouve pas de répertoire rc.d dans etc, tout est fait dans des scripts et dans un fichier qui s'appelle rc.conf et qui utilise une liste de paires clé/valeur.
- Initialisation des logiciels installés en local (je veux dire /usr/local). Dans /usr/local/etc, on trouve un répertoire rc.d qui contient des scripts de démarrage des applis. Ces scripts sont nommées comme suit, 000.pkgtools.sh, doivent se terminer par .sh et être exécutables
- Système d'installation des softs par le mécanisme des ports. Le répertoire /usr/ports contient une série de Makefile classés par thèmes et par appli. Un petit make install dans /usr/ports/net/openldap2 télécharge l'archive d'OpenLDAP, la décompresse, installe si ce n'est déjà fait (d'après /var/db/pkg) les dépendances dans notre cas la lib libiodbc (qui elle se trouve dans /usr/ports/databases). Actuellement, le répertoire des ports contient jusqu'à 7000 ports

Pour ce qui est du plus ou moins sécure, je peux pas vraiment répondre, si ce n'est que même sans customization particulière, ça a l'air de tenir la route.
Sinon, l'admin, c'est comme du Linux, c'est de l'Unix quoi !

Merci de me soutenir !!
A noter qu'après compilation (ou installation) il est de bon goût de lancer ce magnifique outil qu'est mergemaster, pour mettre vos fichiers de conf à jour. La première fois c'est impressionnant !!
C'est clair que c'est impressionnant mais un peu long quand même.

Alors, j'avoue qu'au niveau des sources, je suis plus très sûr. Il me semble que 500 Mo de disque avant compil sont suffisants. Enfin, je sais plus trop et comme je ne suis pas devant ma machine perso ;-)

La récup en cvsup dépend de ta dernière mise à jour ou plutôt de la date des fichiers dans ton /usr/src. Si tu as les sources de la 4.3 par exemple, il faut compter plus de temps que si tes sources datent de la 4.6. En règle général, j'essaye de le faire régulièrement pour maintenir mes sources à jour. L'ordre de grandeur, c'est une petite heure avec un modem 56K sur cvsup2.fr.freebsd.org en faisant la mise à jour tous les deux ou trois mois.
Pour ce qui est du make world, ca prends pas loin de quatre heures sur PII 266. Voilà

Ouais, le cvsup, c'est bien mais se faire un petit jeu de CDs de temps en temps, c'est pas mal non plus. Ca permet d'avoir une sauvegarde ton système à un instant donné puisque bien sûr lors de tes backups, tu ne sauves pas tout bien sûr ;-)
En parlant de backup, un petit lien qui ne fait pas de mal http://www.oreilly.com/catalog/esa3/chapter/index.html(...)

Mais même en 1999, le NIS, ça existait déjà !!! (voire le superbe No centralized security - users must manually synchronize user accounts across servers). Il y a même ça aussi qu'est très drôle même pour 99: Hundreds of available applications. Ben voyons, rien que sur FreeBSD, aujourd'hui, il y a plus de 7000 applis portés ce qui signifie au bas mot 9000-10000 pour Linux. On va quand même pas me faire croire que le nombre d'applis a été multiplié par 50 (ouais, des centaines pour ceux qui diraient que le facteur est 100) en trois ans. De toutes façons, quand j'avais ma Slack en 99, je suis désolé, il y en avait déjà énormément.
Ca m'énerve tiens !!!
Je crois qu'en fait, il n'y a rien à répondre à tout ça.