Parmi les points notables de cette version 4.0 on peut relever la prise en charge de l'architecture UltraSparc III ou de plusieurs gadgets basés sur le processeur ARM. Le travail d''amélioration des pilotes pour les cartes wifi ou pour les cartes Gigabit ethernet continue ainsi que le combat du projet OpenBSD pour obtenir de la documentation de la part des firmes qui construisent ces matériels.
Les principaux outils d'OpenBSD (comme pf le firewall ou CARP qui gère la redondance) sont améliorés et GNU RCS (Revision Control System) est remplacé par OpenRCS. Un gros travail a également été effectué sur le support du contrôle de la vitesse des processeurs en fonction de la charge (SpeedStep ou PowerNow).
Une fonction intéressante est celle apportée par l'outil prebind (qui permet de réduire le temps de chargement de certains programmes). Il est commun dans le monde Linux d'utiliser le prelinking afin de profiter de cette amélioration mais les développeurs d'OpenBSD voulaient que cela ne se paye pas au prix de la sécurité. En effet ce prelinking est incompatible avec le chargement aléatoire des librairies (address space randomization) et cette fonction est cruciale dans un système aussi paranoïaque que l'est OpenBSD. L'outil prebind permet maintenant de maintenir le chargement aléatoire tout en profitant de la rapidité du prelinking.
Le site Softwareinreview propose dès maintenant un aperçu d'OpenBSD 4.0 ainsi qu'un petit guide d'utilisation de cette nouvelle version.
Sur le site O'Reilly on peut lire une interview très complète (et très technique) des principaux développeurs OpenBSD au sujet de cette version 4.0 de leur projet.
Aller plus loin
- OpenBSD (7 clics)
- Les nouveautés (2 clics)
- Liste complète des changements (3 clics)
- Un journal sur la sortie (2 clics)
- L'interview géante (2 clics)
# Deux très bons articles
Posté par gaston . Évalué à 6.
http://www.softwareinreview.com/cms/content/view/55/
http://www.softwareinreview.com/cms/content/view/56/
De plus, pour ceux qui veulent l'installer, un miroir officiel français est à jour ici : ftp://ftp.irisa.fr/pub/OpenBSD/4.0
Pour ceux qui hésitent à tester cet OS, n'ayez pas peur, on retrouve vite ses réflexes après une courte période d'adaptation, la documentation est très bien faite, et pour une utilisation quotidienne sur un ordinateur de bureau multimédia y'a aucun problème.
Le seul bémol serait un plus petit nombre de logiciels disponibles (~3700 ports, a comparer aux ~17000 ports FreeBSD ou ~19000 paquets debian, chiffres à la louche), mais les principaux sont présents : Environnements de Bureau (Kde/Gnome/Xfce/...), Suites bureautiques (OpenOffice 2/Gnome-office/Koffice), navigateurs web (Firefox community edition :)/Konqueror/Epiphany..)
L'essayer, c'est l'adopter.
[^] # Re: Deux très bons articles
Posté par gaston . Évalué à 2.
[^] # Re: Deux très bons articles
Posté par patrick_g (site web personnel) . Évalué à -1.
Certes mais elle est en anglais. C'est pas pour troller mais dans ma distro Linux j'ai les man pages en français et ça aide bien.
Je sais qu'OpenBSD atttache une grande importance à la documentation et que les devs sont fiers de leurs pages de man mais j'aimerais qu'ils s'intéressent également aux traductions.
[^] # Re: Deux très bons articles
Posté par Alexandre . Évalué à 5.
Par contre, je doute qu'ils refusent les contributions.
[^] # Re: Deux très bons articles
Posté par patrick_g (site web personnel) . Évalué à -2.
OpenBSD est fourni avec une abondante documentation sous la forme de pages de manuel, ainsi que d'autres documents relatifs à des applications spécifiques. Un effort considérable est fourni pour s'assurer que les pages de manuel sont à jour et correctes. Dans tous les cas, celles-ci sont à considérer comme la source faisant autorité concernant les informations sur OpenBSD.
Donc cette abondante documentation qui fait autorité n'est pas disponible dans ma langue.
Comment alors puis-je installer et utiliser OpenBSD si j'en ai envie ?
Les devs OpenBSd ont choisis de se concentrer sur les man pages pour la doc. Ils ont une politique stricte qui impose de documenter tous les changements qu'ils effectuent et le résultat c'est que leurs man pages sont complètes et à jour (par rapport à Linux c'est vraiment mieux). Le gros bemol c'est que cette fantastique doc est in english only !
Je sais bien que les devs sont en petit nombre, qu'ils ne peuvent pas tout faire...etc etc
Néanmoins le constat est là : la doc man est uniquement en anglais et cela représente une barrière à l'entrée très importante pour la majorité des gens (certains trolleurs diraient que cette barrière à l'entrée n'est pas pour déplaire aux devs OpenBSD mais je ne suis pas de cette espèce poilue donc je ne dirais rien...).
J'ai suffisamment vu des interviews de devs OpenBSD qui se félicitent de leur excellente doc et qui signalent de façon répétitive que c'est un énorme plus par rapport à Linux pour prendre un peu la mouche à ce sujet. Certes votre doc est excellente mais le problème c'est que 90% de la planète ne peux même pas la lire !
Pour nuancer mon propos il faut signaler la FAQ en français qui est assez complète : http://openbsd.org/faq/fr/index.html
Malheureusement elle est très loin d'être aussi complète et à jour que les pages man.
[^] # Re: Deux très bons articles
Posté par Bapt (site web personnel) . Évalué à 2.
Comment veux tu qu'un projet comme OpenBSD pour lequel les manuels font autorité puisse fournir des docs à moitié traduite (car c'est ce qui se passera au final.) Ils ont décidé (je pense) de tout faire dans une seule langue de ne pas fournir de traduction pour éviter ce genre problème. (Les pages de manuels sont très souvent modifiées).
Maintenant rien n'empêche de mettre en place un projet de traduction des man (certainement jamais intégré dans le socle, mais peut être disponible via les ports.) Ce projet serait grandement apprécié je pense, même si non-officiel.
[^] # Re: Deux très bons articles
Posté par Marc Poiroud (site web personnel) . Évalué à 4.
Euh sincérement, faudrait mettre tes marques pages à jour :
http://manpagesfr.free.fr/
Dernière mise à jour : 1er septembre 2006
les pages man fr pour slackware :
http://poiroud.free.fr/linux/slackbuild/man-fr/
Pour ArchLinux :
http://wiki.archlinux.fr/howto:installation:franciser#instal(...)
-\_/o<
[^] # Re: Deux très bons articles
Posté par Anonyme . Évalué à -5.
J'en ai ras le bol de voir les français pleurer parce que tout est en anglais en informatique, mais ne pas être foutus de sortir un projet francophone décent et utile. Et oui, je suis français.
D'ailleurs vous savez comment on appelle quelqu'un qui parle trois langues ? Un trilingue.
Et quelqu'un qui parle deux langues ? Un bilingue.
Et enfin, quelqu'un qui ne parle qu'une seule langue ?
Un français.
Tu ne veux pas faire l'effort d'apprendre l'anglais ? Revend ton pc et cherche un poste à l'académie française...
/me, qui en a vraiment ras le bol de ce nationalisme de m****.
[^] # Re: Deux très bons articles
Posté par Rork . Évalué à 8.
Bonjour,
Mais pourquoi s'énerver ainsi?
Juste pour rendre un peu le monde meilleur, je te rappelle que tu dialogues avec un être humain. Et le dialogue en haussant la voix et en devenant grossier abouti rarement à faire passer les idées. Ca à souvent juste comme conséquence de mettre ses interlocuteurs sur la défensive.
Alors juste pour que tu participes à l'amélioration de la vision que peuvent avoir les autres sur le français, vu que cela semble te toucher, un peu de courtoisie serait la bienvenue.
[^] # Re: Deux très bons articles
Posté par arnaudus . Évalué à 3.
Il faut arrêter de cacher sa paresse intellectuelle derrière des arguments fallacieux : apprendre une autre langue ne peut décemment pas être considéré comme un apauvrissement culturel.
Bon, et en plus, même si les pages de man étaient traduites, les commandes UNIX restent en anglais, les fichiers de conf restent en anglais, les langages de programmation restent en anglais, les jeux de mots sur les programmes restent en anglais, les logs restent en anglais... Connaitre un minimum d'anglais me semble indispensable pour l'utilisation correcte d'un ordinateur.
Donc oui, OK, tu ne parles pas anglais, c'est triste pour toi, mais au lieu de te battre pour que les man soit traduits, tu pourrais plutôt te battre pour que les gamins apprennent l'anglais correctement à l'école.
[^] # Re: Deux très bons articles
Posté par gilgam . Évalué à 3.
Et bien, même si je me débrouille pas mal en anglais, en italien, et aussi en japonais, je dois t'avouer que certaines pages de man me laissent perplexe et que j'ai du mal à vraiment tout comprendre. j'ai même eu beau les montrer à un anglais non informaticien et il avait lui même du mal à comprendre la tournure des phrases.
Alors certes le français serait un mieux, mais si pas de bras (anglais) pas de chocolat (openbsd)...
Il est vrai qu'il est difficile de râler quand tout est gratuit ;-) non ?
[^] # Re: Deux très bons articles
Posté par mat2546 . Évalué à 5.
C'est pas parce que le nom du commande est en anglais, que dans la plupart des langages de programmation les mots resevés sont en anglais , que l'on peut dire que c'est de l'anglais ( reciproquement pour les fichiers de conf et les logs ) . Pretendriez vous que l'anglais et le programmation sont la meme chose ? Qu'un anglais comprendrait un sripte bash sans problemes ? Et si, il faut deja avoir une certaine facilité avec l'anglais pour comprendre une page de manuel de 1000 lignes .
Je dois dire que je n'apprecie vraiment pas vos tons .
Il y a des personnes qui ont plus de facilité a une langue que d'autres . Ceci ne veut pas dire qu'elles ne peuvent pas utiliser un os comme openBSD .
Alors facile de dire : Il faut travailler l'anglais .
Mais pour ceux qui n'en ont jamais fait et qui ont plus de 30, la tâche est plus que difficile .
Alors faudrait se calmer, parce que vos reponses sont limites insolentes .
[^] # Re: Deux très bons articles
Posté par highleaf . Évalué à 1.
[^] # Re: Deux très bons articles
Posté par mat2546 . Évalué à 3.
D'autres part est ce que j'ai critiqué openBSD ? Bien sur que non, non seulement par ce qu'il est gratuit et ensuite parce que c'est un bon OS . Je ne peux juste pas laisser passer vos remarques desobligeantes et non justifiées c'est tout .
[^] # Re: Deux très bons articles
Posté par Rork . Évalué à 9.
Bonjour,
Tu as donc en gros 2 choix:
- Tu en profites pour améliorer ton anglais.
- Tu choisis un autre OS.
Ce n'est pas pour me moquer. Je suis sérieux.
Je comprend bien que la barrière de la langue t'empêche de profiter d'OpenBSD, mais je pense qu'un jour il est temps de se demander ce que tu peux faire pour y remédier plutôt que d'attendre que des gens te fassent des man en français.
Par contre, ta critique sur le barrage de la langue est tout de même intéressante et constructive.
Mais concernant la question que tu te poses, il y a tout de même une solution que tu peux mettre en oeuvre par toi même, sans attendre.
Bonne journée
[^] # Re: Deux très bons articles
Posté par patrick_g (site web personnel) . Évalué à 3.
Je signale juste que j'ai soulevé ce problème de manière purement réthorique. Je peux parfaitement lire l'anglais et après tout j'ai bien pu lire l'annonce de Theo et les divers articles et interviews necessaires pour rédiger cette news sur la sortie de la version 4.0.
Comme je l'avais fait pour la version 3.9 : http://linuxfr.org/2006/05/01/20747.html
Ou pour la version 3.7 : http://linuxfr.org/2005/05/18/18956.html
Tout ça pour dire que j'aime cet OS et que je me félicite de son existence mais que je tenais à souligner ce point négatif.
[^] # Re: Deux très bons articles
Posté par ZeroHeure . Évalué à 3.
Eh ben ? traduis! ;-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Deux très bons articles
Posté par erik_lallemand . Évalué à 2.
Y'a bien 90% de la planète qui n'a pas accès aux ordinateurs. Je suppose que ceux qui y ont accès ont en moyenne une meilleure maitrise de la langue anglaise que la moyenne planétaire, et je devine que le taux d'anglicisation est encore plus élevé parmi ceux qui comptent vraiment jeter un coup d'oeil dans la doc. Je ne remets pas en cause le fait qu'une doc localisée accélèrerait l'adoption d'OpenBSD mais votre formulation me semble donner une vision disproportionnée du "handicap" de la langue.
[^] # Re: Deux très bons articles
Posté par Fabrice Mousset (site web personnel) . Évalué à 2.
Certes votre doc est excellente mais le problème c'est que 90% de la planète ne peux même pas la lire !
Je suis français et j'aime bien trouvé des docs en français pour bien comprendre ce que m'apporte tel ou tel logiciel.
Mais bon, déjà avoir accès à une doc à jour et complète, c'est que du bonheur à mes yeux.
Et puis si 90% de la planète n'arrive pas à lire de l'anglais combien cela serait pour une doc en français ?!? 99,2% peut-être ?!?
Si on suit ce type de raisonnement, il faudrait écrire les docs en Mandarin pour avoir le plus de personnes capables de la lire à l'échelle de la planète... Mais dans ce panel de personnes, combien en ont réellement envie ?
Bref, je trouve choquant ce genre de propos et totalement hors sujet.
PS: Par contre personne n'interdit de faire des traductions des documentations OpenBSD
[^] # Re: Deux très bons articles
Posté par Mr Kapouik (site web personnel) . Évalué à 3.
le faq en français devrait déjà beaucoup t'aider et sinon il existe de noubreuse documentation en français sur internet.
[^] # Re: Deux très bons articles
Posté par Miod in the middle . Évalué à 4.
Si beaucoup de pages (comme la documentation des fonctions de la libc) sont relativement statiques, en revanche pour les parties du système évoluant plus vite, le risque est grand que les traducteurs ne puissent pas fournir de traduction suffisamment rapidement, ou que les gens n'aient plus du tout de temps à consacrer à cette activité (on le voit très bien avec les traductions du site web, où certaines traductions disparaissent pendant plusieurs années parce que personne n'est là pour fournir l'effort de tenir la traduction à jour).
Ceci dit, comme proposé plus bas dans cette enfilade, on ne verra pas d'un (trop) mauvais oeil un projet de traduction indépendant.
# haaaaaa
Posté par bubar🦥 (Mastodon) . Évalué à 2.
quoi j avais qu' à la faire ? okok
ce qui surprends et ravi toujours avec OpenBSD, c' est l' installtion : c' est du pur bonheur : en 20 minutes montre en main (avec partitionnement manuel) sur un serveur poweredge (plus tout jeune), le système est opérationnel avec une fstab comme on les aime :)
me tarde de l' essayer sur une récup de IBM PowerPC en plus du poweredge.
tellement que j' ai craqué, j' ai DL la version sabo**** de l' iso bootable en attendant de recevoir le CD par Ikarios (qui j' espère ne tardera pas trop)
http://www.ikarios.com/p488-OpenBSD.html
ps : Sir Bergamini maintenait (aussi) un petit script "make_me_a_bootable_openbsd" mais je ne le trouve plus .... quelqu' un aurait le lien SVP ? Merci
[^] # Re: haaaaaa
Posté par theocrite (site web personnel) . Évalué à 2.
En bas de page :
http://www.openbsd-france.org/documentations/fait-moi-une-is(...)
Avec un petit diff :
# Perfs ?
Posté par karteum59 . Évalué à 1.
D'après les tests de http://bulk.fefe.de/scalability/ , il semblait que OpenBSD avaid de sérieux problèmes de performances / scalabilité (ça se dit ?), notamment face aux noyaux Linux2.6/FreeBSD/NetBSD.
Mais depuis, de l'eau a dû couler sous les ponts => qqun sait-il ce qu'il en est maintenant ?
[^] # Re: Perfs ?
Posté par kowalsky . Évalué à 2.
Ensuite, suite à ce bench, NetBSD et OpenBSD ont bosser, et amelioré les point qui pêchait.
Suite à ça, un bench à été refait, je te laisse le soin de le trouver...! :)
[^] # Re: Perfs ?
Posté par Arachne . Évalué à 1.
[^] # Re: Perfs ?
Posté par kowalsky . Évalué à 3.
Parce qu'a moins de mettre un PII, ton lien sera à genou avant ton processeur...! :)
# Prelink
Posté par IsNotGood . Évalué à -4.
Pipo. Prelink de Linux est compatible avec des adresses aléaloires.
M'enfin, une news openBSD sans un troll sur Linux, ce n'est pas une news openBSD.
[^] # Re: Prelink
Posté par gaston . Évalué à 3.
Comme un commentaire de ta part sans un troll ou de la mauvaise foi, c'est pas un commentaire de ta part... :)
[^] # Re: Prelink
Posté par patrick_g (site web personnel) . Évalué à 3.
Dans l'interview O'Reilly que j'ai donné en lien on peut lire ceci :
One of the significant security features in OpenBSD is address randomisation (aka ASLR). Prelinking as implemented in Linux removes the randomisation feature so it would not be compatible with OpenBSD's security goals.
Donc soit c'est toi qui a raison soit c'est Dale Rahn (soit j'ai mal compris mais ça me semble une hypothèse inenvisageable ;-).
[^] # Re: Prelink
Posté par IsNotGood . Évalué à 3.
Plus haut, j'ai parlé de "compatibilité" et non dit que Linux le fournissait. Il y a Red Hat/Fedora qui fournit des fonctionnalités de "random address". Peut-être d'autre, je l'ignore.
Si j'ai bien compris, les adresses aléatoires sont utilisées au chargement pour l'édition de lien et fixer le début de la pile. Une installation typique Fedora fait ça. De même par défaut prelink est installé et activé (prelink des applis toutes les nuits).
L'adresse aléatoire de la pile n'implique pas prelink.
Par contre prelink n'est pas utilisé si le chargement des librairies est mis à une adresse alétoire (c'est le cas par défaut pour pratiquement toute les applis) et/ou si c'est du code indépendant (qui peut-être logé n'importe où et pas seulement pour les librairies ; c'est aussi le cas par défaut depuis FC3 je crois).
Bref, prelink est installé mais dans la majorité des cas non utilisé car "random addresse" est utilisé (ça ne concerne pas la pile).
Quelques info sur ce qui est fait dans RHEL/Fedora : http://people.redhat.com/drepper/nonselsec.pdf
> Donc soit c'est toi qui a raison soit c'est Dale Rahn
J'ai tord.
[^] # Re: Prelink
Posté par neologix . Évalué à 6.
En fait, ça dépend de ce que tu appelles randomization.
Depuis la version 2.6.11 (je crois) du kernel, on a une randomization partielle:
exemple:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int n;
int *c = malloc(sizeof(int));
printf("Pile: %p\n", (void *) &n);
printf("Tas: %p\n", (void *) c);
return 0;
}
Sur mon noyau 2.6.17, j'obtiens ça:
Donc, il y a bien "randomizaton" au niveau de la pile (en fait, aussi au niveau des appels à mmap()), mais pas au niveau du tas.
Mais faut pas croire que c'est la panacée: en effet, enfin la dernière fois que j'ai vérifié, la plage de randomization n'est pas énorme (64 kb pour la pile je crois). Quand tu enlèves les adresses quivontpas (alignement), bah en fait il te reste un ensemble assez restreint de valeurs, du coup rien ne t'empêche de faire une boucle au début de ton exploit.
Pour en revenir à la randomization et prelink:
http://lwn.net/Articles/121845/
Quand tu y penses, c'est carrément logique.
Néanmoins, voici ce qu'on peut lire:
Voilà voilà.
Enfin, je crois qu'on se retrouve toujours face au dilemme rapidité/sécurité. Entre les deux, il te faut choisir :-)
[^] # Re: Prelink
Posté par neologix . Évalué à 3.
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int n;
int *c = malloc(sizeof(int));
printf("Pile: %p\n", (void *) &n);
printf("Tas: %p\n", (void *) c);
free(c);
return 0;
}
P.S: on écrit "j'ai tort", et non pas "j'ai tord".
[^] # Re: Prelink mais rien a voir
Posté par Brice2Nice . Évalué à 2.
moyen mnémotechnique, le tort tue (génial)
[^] # Re: Prelink
Posté par IsNotGood . Évalué à 1.
Et ton exemple (très parlant) est pour la pile/tas, non pour les adresses des fonctions.
> Depuis la version 2.6.11 (je crois) du kernel, on a une randomization partielle:
Regardes du côté de Fedora/Red Hat, il y a une randomization complète (avec exec-shield) mais ça ne marche pas pour prelink. Au chargement les adresses données par prelink sont ignorées (prelink est donc ignoré). On peut "réactivé" prelink mais les bibliothèques auront une adresse fixent (celles définis par prelink au moment de l'exécution de prelink).
[^] # Re: Prelink
Posté par neologix . Évalué à 2.
Oui. Mais comme je l'ai dit, ça s'applique aussi à mmap(), donc aux librairies dynamiques.
Pour exec-shield, ça a l'air pas mal. Je ne comprends pas pourquoi Debian ne propose pas un noyau déjà patché (même si c'est désactivé par défaut), ce serait plus pratique que d'avoir à télécharger le patch, l'appliquer etc.
Tiens, ce serait une bonne idée une version de noyau "serveur", avec un noyau durci.
[^] # Re: Prelink
Posté par neologix . Évalué à 2.
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int n;
int *c = malloc(sizeof(int));
printf("Pile: %p\n", (void *) &n);
printf("Tas: %p\n", (void *) c);
printf("Librairies: %p\n", (void *) fopen);
free(c);
return 0;
}
Me renvoie:
Bon, je sais que ce n'est pas ANSI de convertir un "function pointer" en "object pointer" (comment l'imprimer proprement?), mais n'empêche que ce n'est pas ce que j'attendais. Va falloir que je regarde ça de plus près, ça m'intrigue.
# question bete
Posté par Anonyme . Évalué à 1.
j'aurais tendance a dire - téo de rate - mais sans grande conviction
[^] # Re: question bete
Posté par coolix . Évalué à 1.
http://fr.wikipedia.org/wiki/Theo_de_Raadt
# GNU RCS -> OpenRCS: pourquoi ?
Posté par Xavier Maillard . Évalué à 0.
C'est une marque de fabrique ? Qu'est-ce qui les dérange dans la version GNU ?
Ou bien c'est une question de principe: reprendre tout GNU et en faire un Open trucmuche ?
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par Mr Kapouik (site web personnel) . Évalué à 7.
Selon théo : la licence GPL n'est pas libre a coté de la licence BSD qui est extrèmement permissive (proche du domaine publique). Bref dans un soucis d'avoir une distribution 100% BSD, les outils GNU sont refait petit a petit ce qui n est pas une mauvaise chose selon moi ...
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par Xavier Maillard . Évalué à -2.
Est-ce vraiment "legal" dailleurs ? A-t-on jamais tenté de demander à la FSF ce qu'elle pensait de ces ré-écritures "sauvages" ?
/me va se faire une joie de demander l'avis du guru.
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par gaston . Évalué à 4.
Et extrait de la manpage ( http://www.openbsd.org/cgi-bin/man.cgi?query=rcs&sektion(...) ) :
C'est autant pour améliorer RCS coté sécurité que pour se débarasser d'un autre outil GNU présent dans le système de base... Après ca, il faudra s'attaquer a OpenCVS, et après on se prend à rêver à OpenGCC et OpenHTTPD :) :)
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par Antoine . Évalué à 2.
C'est quoi l'intérêt de réécrire ces dinosaures obsolètes ?
Aujourd'hui tout le monde passe graduellement à Subversion ou à un des systèmes de développement distribué (Mercurial, etc.), qui n'ont aucune dépendance à ma connaissance sur RCS/CVS.
Faire du bon logiciel, c'est aussi savoir ne pas s'acharner sur des causes perdues ou dépassées.
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par Bapt (site web personnel) . Évalué à 2.
La première brique est là : le remplacement de GNU RCS par OpenRCS.
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par reno . Évalué à 2.
L'utilise ok, mais de là a l'aimer a mon avis, ils sont pas si nombreux que ça!
Le gros avantage de CVS c'est sa simplicité et en cas de problème, tu peux sortir vi et corriger le problème a la main dans les archives directement, le gros problème de CVS c'est que les problèmes arrivent un peu trop souvent, avec le commit non atomique notamment et qu'il est très limité.
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par panda panda . Évalué à 3.
La problematique d'OpenBSD (le premier systeme d'exploitation a utiliser un repertoire CVS completement public pour la gestion des sources) est simple: son developpement repose sur un outil qui a ses limites tant en matiere de securite que de fonctionnalites (les fameux commit atomiques, possibilite de deplacer des repertoires).
Comme d'habitude la reponse d'OpenBSD est pragmatique:
1. implementer un jeu d'outils compatibles: en l'occurence reecriture de rcs et cvs
2. apporter des nouvelles fonctionnalites
sur le moyen terme (2 ou 3 releases) on devrait voir apparaitre des nouvelles fonctionnalites dans OpenCVS.
Et au passage il faudrait lire les releases notes, parce qu'outre OpenRCS, de nombreux projets ont avance en parallele, bgpd et ospfd sont de plus en plus murs, ripd vient d'etre importes. hostapd, ipsecctl et sasyncd ont tous bien evolues...
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par Antoine . Évalué à 2.
Comme d'habitude la reponse d'OpenBSD est pragmatique:
La réponse pragmatique est d'abandonner CVS et de passer à Subversion, qui est le standard remplaçant et corrige les problèmes sus-cités (entre autres). Sans compter que Subversion est capable de réutiliser des protocoles existants (HTTP/HTTPS) au lieu d'une bidouille ad-hoc comme pserver.
Au contraire, vouloir réimplémenter ce genre d'améliorations en gardant l'infrastructure archaïque de CVS (tu as vu à quoi ressemble le format de stockage ?), c'est clairement aller dans une impasse. Et réécrire un machin obsolète graduellement abandonné par les utilisateurs, c'est pas vraiment "pragmatique". Ils réécrivent Tcl-Tk aussi ?
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par Mr Kapouik (site web personnel) . Évalué à 1.
Chaque alternative offrira toujours un avantage (à moins qu'elle soit programmé avec les pieds).
Et pour la question : est ce illégal ?
RMS n'a pas inventer Unix avec GNU et la FSF donc tu as le droit de programmer des outils pour un système d'exploitation sous la licence que tu veux et qui font ce que tu veux. Crois tu vraiment que bash ou gcc soit illégal parce qu'ils font la même chose que des outils concurant ?
Si toute alternative devient illégal à ton sens alors je pense que tu devrai reconsidérer ta vision du monde ...
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par erik_lallemand . Évalué à 1.
Au moins en France, oui, c'est légal. On entre là dans un pendant du débat sur les brevets logiciels. Pour faire simple (voire simpliste), un logiciel se décompose en:
- une idée (cahier des charges)
- une implémentation (le code source)
Le code source relève du droit d'auteur. On ne peut pas le copier ni le modifier sauf mention explicite de l'auteur (ce qui se fait en général via les termes de licence... GPL, BSD, Apache...)
L'idée appartient à tout le monde. Tout le monde a le droit de créer un logiciel reprenant des fonctions similaires à un autre logiciel. Par exemple, OpenOffice.org reprend des fonctonnalités qui existaient auparavant dans MS Office. Ou PostrgreSQL reprend des fonctionnalités qui existaient en Oracle.
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par IsNotGood . Évalué à 3.
La liberté ça se défend. C'est le sens des exigences de la GPL.
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par Brice2Nice . Évalué à 3.
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par herodiade . Évalué à 3.
Ce qui se devine facilement :
s2t0c$ find /usr/src/gnu/usr.bin/cvs/ -type f -name '*.c' | xargs wc -l | tail -1
102145 total
( plus 11 000 lignes de headers, 24 000 lignes de shell script etc.).
À cette époque (et même depuis lors), GNU CVS a mangé quelques râteaux, en matière de sécu.
# Et aussi, sortie de OpenBGPD 4.0
Posté par herodiade . Évalué à 5.
Et bien ce bougre d'OpenBGPD est sorti le même jour, avec tout un tas de nouvelles fonctionnalités qui sont indiquées ici :
http://undeadly.org/cgi?action=article&sid=2006110115435(...) .
Certains développeurs d'OpenBSD travaillent en effet activement au développement de toute une batterie de serveurs de routage : on a déjà, au menu, un serveur BGP (celui dont je parle), un serveur OSPF (OpenOSPFD), un serveur dvmrp/IGMP (dvmrpd), et tout récemment un serveur RIP (ripd, qui devrai remplacer avantageusement le vieux routed).
Quant à l'annonce de la release d'OpenBSD, dommage qu'elle passe sous silence les énormes progrès d'ipsecctl(8), un outil à la configuration super simple et ergonomique qui paramètre la pile IPsec du noyau et le serveur de clef ISAKMPD (lequel a une conf à la syntaxe plus tortueuse, mais qu'on a plus besoin d'écrire soi-même, grâce à ipsecctl).
# Version cohérente...
Posté par rewind (Mastodon) . Évalué à 1.
J'ai toujours été étonné par les x.10 après les x.9, c'est illogique au possible et quand on navigue dans un répertoire, ça casse l'ordre naturel des versions. Ou alors, il faudrait faire x.09, ça serait cohérent. Donc merci à OpenBSD de montrer la voie (comme toujours) !
[^] # Re: Version cohérente...
Posté par Miod in the middle . Évalué à 3.
Une autre solution consiste à préfixer par une lettre, pour pouvoir continuer à utiliser .10 et garder l'ordre lexicographique, c'est ce qu'a fait HP-UX avec les version 8.*, puis A.9.*, puis B.10.*.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.