Linus on Subversion, GPL3, Microsoft and More 350
victor77 writes "Linus has repeatedly slammed Subversion and CVS, questioning their basic architecture. Subversion community has responded...how valid is Linus's statement?" This and many other subjects are covered in this interview with Linus.
Linus would not be pleased... (Score:1, Informative)
[Microsoft][ODBC SQL Server Driver][SQL Server]Transaction (Process ID 182) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Article (Score:3, Informative)
Q: What are the future enhancements/paths/plans for the Linux kernel? --Subramani R
Linus: I've never been much of a visionary -- instead of looking at huge plans for the future, I tend to have a rather short timeframe of 'issues in the next few months'. I'm a big believer in that the 'details' matter, and if you take care of the details, the big issues will end up sorting themselves out on their own.
So I really don't have any great vision for what the kernel will look like in five years -- just a very general plan to make sure that we keep our eye on the ball. In fact, when it comes to me personally, one of the things I worry about the most isn't even the technical issues, but making sure that the 'process' works, and that people can work well with each other.
Q: How do you see the relationship of Linux and Solaris evolving in the future? How will it benefit the users?
Linus: I don't actually see a whole lot of overlap, except that I think Solaris will start using more of the Linux user space tools (which I obviously don't personally have a lot to do with -- I really only do the kernel). The Linux desktop is just so much better than what traditional Solaris has, and I expect Solaris to move more and more towards a more Linux-like model there.
On the pure kernel side, the licensing differences mean that there's not much cooperation, but it will be very interesting to see if that will change. Sun has been making noises about licensing Solaris under the GPL (either v2 or v3), and if the licence differences go away, that could result in some interesting technology. But I'm taking a wait-and-see attitude to that.
Q: Now that the GPLv3 has been finalised and released, do you foresee any circumstance that would encourage you to begin moving the kernel to it? Or, from your perspective, is it so bad that you would never consider it? -- Peter Smith / Naveen Mudunuru.
Linus: I think it is much improved over the early drafts, and I don't think it's a horrible licence. I just don't think it's the same kind of 'great' licence that the GPLv2 is.
So in the absence of the GPLv2, I could see myself using the GPLv3. But since I have a better choice, why should I?
That said, I try to always be pragmatic, and the fact that I think the GPLv3 is not as good a licence as the GPLv2 is not a 'black and white' question. It's a balancing act. And if there are other advantages to the GPLv3, maybe those other advantages would be big enough to tilt the balance in favour of the GPLv3.
Quite frankly, I don't really see any, but if Solaris really is to be released under the GPLv3, maybe the advantage of avoiding unnecessary non-compatible licence issues could be enough of an advantage that it might be worth trying to re-license the Linux kernel under the GPLv3 too.
Don't get me wrong -- I think it's unlikely. But I do want to make it clear that I'm not a licence bigot, per se. I think the GPLv2 is clearly the better licence, but licences aren't everything.
After all, I use a lot of programs that are under other licences. I might not put a project I start myself under the BSD (or the X11-MIT) licence, but I think it's a great licence, and for other projects it may well be the right one.
Q: Currently are there any Indians who you'd like to highlight as key contributors to the Linux kernel?
Linus: I have to admit that I don't directly work with anybody that I actually realize as being from India. That said, I should clarify a bit: I've very consciously tried
Alternate link (Score:4, Informative)
http://www.efytimes.com/archive/144/news.htm [efytimes.com]
Re:Can't RTFA... (Score:5, Informative)
The article linked here is light on details concerning SCM, though.
Re:Can't RTFA... (Score:5, Informative)
And here is the reaction from the subversion team [tigris.org]. For those of you who don't want to RTFA, they basically say they agree, its not appropriate for something like Linux.
BTW, isn't this all old news? His original comment on subversion was dated from 05
Re:Article Summary Misleading (Score:5, Informative)
Think that could be because its an Indian news site and the guy himself is Indian?
Believe it or not, just because something is published on the world wide web doesn't mean it has to cut out everything of local interest.
Re:Article (Score:3, Informative)
Re:Linus would not be pleased... (Score:5, Informative)
oracle is all great and fun if you have the money to cough up for it. sql server has great performance at a fraction of oracle's cost. of course, a competent architect will know when to use sql server and when to use oracle.
Other subversion flaws (Score:3, Informative)
I just had to have a polite conversation with a professional peer who kept his home directory on his laptop, then turned on NFS shares "to get work done". I waited, very politely, until he put his laptop on the DMZ with his NFS shares turned on. Then I pulled his SSH keys for a set of sourceforge projects from his directory, and his password from his oher Subversion repositories. Voila! I now have write access to his Sourceforge subversion epositories.
I'm patient. But crackers aren't, and scan for this sort of vulnerability constantly. The Subversion authors should never have bothered to include the ability to store the password, at all.
PARADIGM SHIFT! (Score:5, Informative)
If you really want to know what Linus is talking about from the man himself, watch this Google Tech Talk. It's over an hour, but there's nothing like hearing it straight from the horse's mouth.
http://video.google.com/videoplay?docid=-21993320
Re:Can't RTFA... (Score:3, Informative)
Too bad Continuus costs too much to try, I think he would want to return to SVN after using that piece of shit.
Re:Can't RTFA... (Score:2, Informative)
- Not mess up my working directory with a bunch of
- As somebody else said, proper branching & tagging
- Related to the
- While getting better, it isn't very fast dealing with large working copies (say, 200+ megs)
Re:Can't RTFA... (Score:5, Informative)
I used to use CVS (and still do for some projects). Then I switched over to SVN. It was remarkably unremarkable.
Then, a few months ago, there was a /. article on git [git.or.cz]. It sounded interesting so I tried it... and was thoroughly impressed.
I was up and running in about 20 minutes. You can use cvs/svn like commands, *but* you get local / decentralized repositories with fast forking and merging.
Start a project. Type "git init" and you've got a repository in place (you don't have to initialize and then check it out). "git add ." and "git commit" and you've got your first revision.
It took a little bit more effort to figure out how to push/pull from a remote repository, but it's fairly straightforward. A bunch of people can work in a group, have their own local repositories, and then merge their changes (along with the revision history). It's awesome.
The only reason I haven't switched all of my projects over to it is that the IDEs I use (Xcode and Eclipse) don't have good git integration (as far as I know).
Re:if it isn't broken (Score:3, Informative)
Re:Other subversion flaws (Score:1, Informative)
Considering that both the ssh keys folder and the subversion authorization folders are both chmod 700 by default, it doesn't matter if he tosses up an NFS share. You still cannot access it without being him or root. And of course if you had his password anyway then trying to access his password by him sharing his home directory is pointless anyway as you could simply just ssh into his computer and grab it. I call shenanigans on this one.
As I mentioned above, by default, without the author changing permissions manually, the passwords are accessible only to the user. Even the group and world are not allowed access into the folder much less the files in them. And for those of us who live in the real world with real enterprise grade software to work on that span a dozen different repositories with at least 6 different authentication systems, yeah remember passwords is a godsend.
Then again, all my "file sharing" happens with a special user account that is nothing but filesharing and I just have symlinks into that user. And it is all samba based filesharing not NFS and it is locked down with a user/password to even access the samba share.
Subversion *does* have many flaws but the storing of passwords is not one of them. That is almost a mandatory feature requirement to work with repositories in most development organizations.
Re:Other subversion flaws (Score:3, Informative)
Re:Can't RTFA... (Score:2, Informative)
The trick is to get svnmerge. It handles almost all of the nitty gritty details so you can actually do what you realy want to do, which is "take the changes from branch A and put them into branch B". Say you want to take the junk in changeset 1,2,5 and all the junk between 30 and 35 and merge it into your working copy:
> svnmerge merge -r 1,2,5,30-35
First, it remembers where you want to pulls stuff in from - you set that when you initialize a branch by telling it "link the branch in this working copy to branch svn://somewhere/else/". Every time you run it, it looks at what hasn't been merge into your working copy. You can get a list of junk it hasn't merged with:
> svnmerge avail
Once you do the "svnmerge merge" it will pull in all the changes and automatically keep track of what it just merged it. You then do a regular commit on the changes and off you go. I usually do this:
> svnmerge merge -r 4,5,6 -f commit.txt || svn commit -F commit.txt || rm commit.txt
That command pulls in the revisions to your working copy and creates a commit log "commit.txt". It then commits your crap and removes the log.
The whole thing is a hackjob for sure, for starters TortiseSVN doesn't know about it and I'd love to do the whole process in some GUI thing. But it does show you that SVN itself is more than capable of handling merges in a "proper" way. Subversion just needs to get this hi-level stuff into it's own codebase so it knows what is up. I know they are working on it, I just hope that I can migrate from svnmerge to whatever native stuff they cook up in an elegant fashion.
Don't get your hopes up (Score:3, Informative)
"Merge Tracking in Subversion 1.5.0 is roughly equivalent in functionality to svnmerge.py, recording and using merge history to avoid common cases of the repeated merge problem, and allowing for cherry-picking of changes." -- http://subversion.tigris.org/merge-tracking/ [tigris.org]
Re:Can't RTFA... (Score:4, Informative)
See also: 0.10 history [kerneltrap.org], 0.02 & 0.03 history [kerneltrap.org], 0.01 history [kerneltrap.org]
Re:"use git as if it were centralized" (Score:3, Informative)
My goal of a "perfect" version control system is one that is decentralized, but lets me decide how much history I want, and lets me decide if something is so old as to be irrelevant, not worth having locally. If older versions can be discarded without impacting day-to-day work, why have I not seen this as an option for any decentralized systems?
It is one of those "seems obvious enough to me that I am probably just using the wrong keywords in Google" things.
SVN lets me check out just the "most recent" copy, and I can pull whatever I need from the remote repository if I need it.
git, from what I've read, does not.
I am not trying to be arrogant here, I would love to be corrected. Given history of other times I've asked this question, I don't expect to.
Re:"use git as if it were centralized" (Score:3, Informative)
Perhaps I use SVN in situations where something simpler would suffice, but I
mostly, though, it's just the idea of "we don't want to import 3 years of history, it's not worth it right now" + "And this is good for the long term!"
Re:"use git as if it were centralized" (Score:3, Informative)
http://kerneltrap.org/node/5014 [kerneltrap.org]
Just because I'm the type of person who uses version control and often have access to high-speed internet and large hard drives doesn't mean I'm
As for "give it a try", I did, but very early in its history so I don't think enough niceties were there at the time.
Mostly, it comes down to: sometimes my SVN repository grows very quickly due to all the sometimes unneeded history. There's no "svn obliterate", so we just put up with it. This causes (actual, not hypothetical) storage issues even with centralized version control. I wouldn't want to multiply this problem by the number of developers, while adding bandwidth issues previously not dealt with because some things they just didn't care about, just to allow them access to histories