On Sun, 18 Nov 2012 00:59:54 -0500, grarpamp wrote: > > Never trust an operating system you don't have sources for. ;-) > > As well summarized by this (your signature) ... sources you can't > verify to the master are, also, sources you can't trust.
Unless. of couse, you are able to "use the source Luke" and spot malicious portions by yourself. This of course is usually possible to subsets only, and mostly to the gurus of our guild. The "ordinary user" won't be able to do this. > >> fi...@ukr.net > > LOL And how will this help Linux? > > http://lwn.net/Articles/457142/ > > How will what help Linux? Please quote a relevant snippet instead > of the entire message. > > Seems pretty clear from the above link that having hashes/crypto > as an intrinsic feature of the SCM tool does in fact help Linux. The article's headline is "kernel.org compromised", and the significant part (as of August 2011!) is: Earlier this month, a number of servers in the kernel.org infrastructure were compromised. We discovered this August 28th. While we currently believe that the source code repositories were unaffected, we are in the process of verifying this and taking steps to enhance security across the kernel.org infrastructure. However, this is a Linux problem, not a FreeBSD one, regarding repository infrastructure. > >> utis...@gmail.com > > Yes, but git doesn't work with our workflow. > > There's usually a larger than head sized sandbox near everyone's > local neighborhood. Will people elect to visit it, or to learn, > grow, and change for the better? In many contexts, "better" _depends_. > Prioe workflow is often forced by > and derived from the tools being used. That is _one_ (valid!) way to see it. Another way is that tools will be chosen according to established workflows, or tools will adapt those workflows to better support them. > Different tools could enable > different, more useful workflows. SVN required workflow change from > CVS, people managed just fine. If the required programs will be integrated in the OS, accompanied by proper documentation, and the backend infrastructures being instantiated, up and running, I don't see a big problem. Unlike in other "OS countries", FreeBSD people are able to adapt to new methods and tools. > > [git] ... is GPL btw > > FreeBSD does not include this sort-of-BSD licensed SCM tool in its > base either... > > # https://svn.apache.org/repos/asf/subversion/trunk/LICENSE > # ls /*bin/svn /usr/*bin/svn > ls: No such file or directory > > But it does include this GPL licensed one... > > # http://cvs.savannah.gnu.org/viewvc/cvs/ccvs/COPYING?revision=HEAD > # ls /*bin/cvs /usr/*bin/cvs' > /usr/bin/cvs > > And of course we have this in use as well... > > # perforce > http://www.perforce.com/purchase/pricing-licensing > > So it seems license is not an obstacle to inclusion, and certainly > not the use via ports, of any particular SCM with the FreeBSD > project. As far as I know, FreeBSD team puts much work into getting the OS into a "BSD license only" state, making it more appealing to commercial use where the (often so called) "rape me license" BSDL is very welcome. But as for "being part of the OS installation", you are right: Whatever tool will be required (or at least suggested) for the purpose of managing "CVS-like" functionality for sources and the ports collection should be part of the basic installation. That's why "pkg_add -r cvsup-without-gui" (if I remember correctly) has been the way in the past, but then, a rewrite called csup became part of the default installation, so you could use the known cvs command _and_ have a nice integration with system functionality, like entries in /etc/make.conf and configuration files for _how_ to update sources, ports, documentation and so on (e. g. in /etc/sup, with /usr/share/examples/cvsup/ as examples), so "make update" would do whatever you wanted. Exactly that kind of productive (!) behaviour is what I would expect (or at least wish) for any replacement of CVS, be it SVN or Git. > Sorry to reply to these sorts of replies this way, but please, this > isn't a troll or a shed. No need to do that around the issue raised. > Hash [ :-) ] it out and solve it. With some salt, please. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
