Une intrusion a été détectée sur 2 machines de FreeBSD.org. Ces machines ont été isolées et éteintes. A priori la compromission ne serait pas due à une faille au sein de FreeBSD mais de la fuite d'une clef ssh d'un dev.
Plus d'infos sur le site de FreeBSD : http://www.freebsd.org/news/2012-compromise.html
# SCM propriétaire
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Remarque sans rapport avec l'intrusion en question :
Ça m'aura permis de découvrir que le projet FreeBSD utilise un outil de gestion de versions propriétaire (Perforce). Cf http://www.freebsd.org/doc/en/articles/p4-primer/index.html « The FreeBSD project uses the Perforce version control system to manage experimental projects that are not ready for the main CVS repository. »
[^] # Re: SCM propriétaire
Posté par BAud (site web personnel) . Évalué à 2.
freely = gratuitement, si j'ai bien suivi. À quand LibreBSD pour enlever toute confusion ? (le terme Libre Software étant repris dans l'acronyme FLOSS et compréhensible par les anglophones connaissant l'espagnol ou le français…).
[^] # Re: SCM propriétaire
Posté par fravashyo . Évalué à 3.
oui c'est un peu bizarre, idem pour leur forum qui utilise vbulletin : http://forums.freebsd.org/
avec l'argument : "on prend le meilleur outil", alors qu'il existe quand même de bons logiciels de forum libres…
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: SCM propriétaire
Posté par rewind (Mastodon) . Évalué à 10.
Utiliser du propriétaire d'un côté, et tout faire pour remplacer le GPL par du BSD de l'autre. Moi j'appelle ça de la schizophrénie…
[^] # Re: SCM propriétaire
Posté par dyno partouzeur de drouate . Évalué à 4.
l'inverse aurait été pire. BSD n'est pas incompatible avec le propriétaire, conotrairement au GPL.
[^] # Re: SCM propriétaire
Posté par ckyl . Évalué à 4.
L'histoire des VCS de FreeBSD est assez intéressante et surprenante à la fois. Il y a un très bref aperçu ici: http://wiki.freebsd.org/VCSWhy
Je profite de la digression pour demander des retours d'expérience sur l'utilisation d'un dépot CVS avec un outil local ne tuant pas la productivité. Je suis à la recherche d'une solution performante pour retrouver la productivité que l'on peut avoir avec les outils modernes.
[^] # Re: SCM propriétaire
Posté par BAud (site web personnel) . Évalué à 1. Dernière modification le 18 novembre 2012 à 01:45.
ça dépend, au siècle dernier ou dans les dix dernières années ?
eclipse ?
bin redmine gère git et c'est en Ruby, sinon, ya VHFFS que tu peux aussi installer chez toi, les deux gèrent un truc du siècle dernier comme CVS mais aussi subversion et git (voire mercurial).
[^] # Re: SCM propriétaire
Posté par ckyl . Évalué à 4.
M'enfou ;)
D'après mes tests l'utilisation de DCVS en client forcément n'est pas forcément génial (mais l'avis de quelqu'un qui à un peu poussé le truc serait intéressante). Il reste les outils de patchs management que je n'ai pas encore trop regardé.
Eclipse c'est uniquement le moins pire. Dès que tu as besoin d'empiler des patchs qui touchent au mêmes fichiers, de branches, de revenir dans l'historique c'est la mort.
Tu penses bien que si je pose la question c'est qu'il y a une raison. Et donc me répondre d'utiliser un autre type de dépôt ne m'avance guère ni ne répond à ma question.
[^] # Re: SCM propriétaire
Posté par BAud (site web personnel) . Évalué à 3.
La petite pique sur CVS était une façon détournée d'indiquer que si svn puis git et mercurial sont désormais disponibles, c'est bien que certaines limites ont été atteintes et que de nouvelles fonctionnalités étaient nécessaires ;-)
La gestion de code (et ses différentes branches, gestion de merge…) est un vaste sujet, tu pourras trouver quelques articles de Linus, notamment, indiquant son workflow et ce qu'il avait besoin de faire. Concrètement, tu rencontres quelles difficultés, qu'attendrais-tu spécifiquement comme améliorations ?
[^] # Re: SCM propriétaire
Posté par ckyl . Évalué à 3.
Je pensais juste que je traînais ici depuis assez longtemps ici pour que tu m'épargnes cette étape ;) Elle aurait déjà été inutile il y a 10 ans où IIRC j'avais les limites de CVS déjà bien en tête et l'avais même souvent remplacé par un DCVS ou svn…
Concrètement on peut oublier toute les problématiques du côté dépôt (archéologie sur la base, branche/tag publique) c'est inévitable et on ne peut que pleurer.
Par contre j'ai besoin de pouvoir bosser sur plusieurs trucs en parallèles dont le développement et la validation sont assez longs. En gros un patch ou une suite de patch peut traîner quelques jours/semaines avant que je pousse où que j'envois pour review. Bref j'ai vraiment besoin d'avoir un équivalent de branches locales et de pouvoir ensuite facilement pousser mes changesets et me synchroniser avec le dépot.
Bref l'équivalent d'un git-svn même bien castré serait parfait. J'ai commencé a tester git-cvsimport/git-cvsexport mais pour le moment ça me semble assez bancale. Comment bossent les autres, ou le workflow du projet je m'en fou. Je veux juste pouvoir travailler tranquillement dans mon coin sans produire de la merde et perdre 10x plus de temps qu'avec un DCVS pour faire la même chose. On peut voir l'étape de pousser sur le CVS comme pousser sur un repo externe. Si ils perdent toutes les metadatas ou autre je m'en fou.
[^] # Re: SCM propriétaire
Posté par BAud (site web personnel) . Évalué à 2.
oui, comme tu me le dis quasi à chaque fois et, vu que je ne m'en lasse pas, bin je continue :D
Vu que LinuxFr.org est un site ouvert à tous, je ne vois pas de souci à expliciter certaines private jokes, ce qui permet de préciser la demande au passage :)
[^] # Re: SCM propriétaire
Posté par ckyl . Évalué à 4. Dernière modification le 19 novembre 2012 à 09:03.
J'avoue sans problème essayer de faire des réponses adaptées et utiles à l’interlocuteur (dans le doute j'ai tendance à considérer les gens comme des grandes personnes). Dans le cas présent, sauf à avoir un fort soupçon que le type à raté l'évolution des VCS depuis 2000 je me dirais que si il demande comment rendre CVS moins pénible en local lui dire que d'autres types de repository existent, et qu'il n'a qu'à changer de repo ne va pas l'aider des masses.
J'avoue sans problème non plus qu'une meilleur formulation de la question aurait été: Il faut que j'utilise CVS, c'est quoi le meilleur client CVS qui permet d'avoir un historique local, des branches locales et une synchronisation bidirectionnelle ? Un git-svn like quoi.
[^] # Re: SCM propriétaire
Posté par cosmocat . Évalué à 2.
je connais pas cvs mais en demandant à un pote (Google), j'ai trouvé çà :
http://stackoverflow.com/questions/584522/how-to-export-revision-history-from-mercurial-or-git-to-cvs/586225#586225
je sais pas si ça répond à ton besoin…
[^] # Re: SCM propriétaire
Posté par Firwen (site web personnel) . Évalué à 3.
git cvsimport est comme osn nom dl'indique tout juste bon à importer un repo CVS sous git, c'est trés trés loin de ce que tu peux faire avec git-svn qui lui te permet de garder ton dépot local git synchronisé avec un dépot SVN sans trop de peine.
Bref, ça dépanne mais c'est loin vraiment utilisable.
Ceci dit, j'aurai envie de dire qu'en 2012 celui qui tourne encore sous CVS merite un coup de pied au cul, mais ce n'est que mon avis…. :D
[^] # Re: SCM propriétaire
Posté par ckyl . Évalué à 2.
Pour le lien je l'avais déjà trouvé. J'ai commencé à expérimenter cette semaine mais pour le moment j'arrive pas à être super convaincu que ca va le faire. D'où l'appel à des gens qui auraient expérimenté en vrai.
Normalement tu peux ressortir le tout avec cvsexport. Reste à voir qu'il n'explose pas en vol vu les concepts totalement différent des deux.
On est entièrement d'accord. Mais ça ne m'avance absolument pas ;)
[^] # Re: SCM propriétaire
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 6.
En fait, il conviendrait de ré-écrire cette phrase à l'imparfait. Perforce était utilisé quand le projet utilisait encore CVS, mais depuis la migration vers SVN, il est pratiquement devenu inutile.
# Vive la compil
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
En lisant le rapport, on voit que les machines touchées faisaient partie du cluster permettant la construction des packages des logiciels tiers (donc hors base).
On voit aussi que les repo SVN et Perforce ont été audités et que rien n'a été touché.
Conclusion : Sous BSD, il vaut mieux toujours utiliser les sources via les ports plutôt que les packages :)
[^] # Re: Vive la compil
Posté par Naha (site web personnel) . Évalué à 2.
Sous FreeBSD peut-être, mais ne généralisons pas : OpenBSD recommande au contraire l'utilisation des paquets binaires plutôt que de compiler depuis les ports.
Source : http://openbsd.org/faq/faq15.html#Ports
[^] # Re: Vive la compil
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Enfin, cette fois-ci, c'eut été un mauvais conseil !!
D'ailleurs, j'ai du mal à voir la justification, les avantages de la compilation étant :
- colle au plus près à l'architecture de la machine (pas de compatibilité avec un truc antédiluvien)
- permet de passer des options de compilation non utilisées pour les mêmes raisons
Par contre, c'est pas forcément pour les newbies mais c'est quand même pas la mort à utiliser.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.