login
Search
The latest kernel trap is out. A lot of discussion on SCM (not just BitKeeper) this week as well some notes about the SSSCA and the zlib security affecting the kernel.
1.Some Discussion Of The SSSCA
2.Some Dissent Over BitKeeper
3.Seeking A Free Alternative To BitKeeper
4.BitKeeper Repositories
5.Status Of Asymmetric Multi-Processing Support
6.zlib Security Vulnerability
latest kernel trap?
One could say that the latest kernel _traffic_ is out :)
Oops
I was pleased enough to get the links correct this time :-)
Alex
Prefix Usage
And we should maybe use Jeremy's rule to prefix Linux articles with "Linux: ", OpenBSD articles with "OpenBSD: " etc.
--
I used to have a sig until the great Kahuna of FOOness
told me to dump it and use /dev/urandom instead.
Re: Prefix Usage
>And we should maybe use Jeremy's rule to prefix Linux articles with
>"Linux: ", OpenBSD articles with "OpenBSD: " etc.
Hmm. great idea! 8D
i had never noticed that :\
9 pages for bitkeeper, 5 for linux news
Come on, what is the deal here, for me there are 9
screenfuls of Bitkeeper news and 5 screenfuls of
linux news.
Bloody hell, it's been like this for the last month.
I give up, kernel traffic can rot.
BK HOWTO is not helping
http://kt.zork.net/kernel-traffic/kt20020304_156.html#4
The above link is to an item called "BitKeeper Kernel Hacking HOWTO",
the title of which is in large font and the body of which makes up
more than 50% of that issue of kernel traffic.
I agree that the licensensing issue is very important, I think the
use of bitkeeper is an absolutely terrible thing.
Linus suffers from all the problems of Open Source. Open source is
argued for in terms of it's technical superiority and cost
effectiveness instead of the freedoms it gives it's users.
"I personally refuse to use inferior tools because of ideology."
How does one argue against that?
I don't think the position Kernel Traffic has taken is doing much
to help highlight the issues of freedom, tutorials, HOWTOs and
discussions between the core hackers about how best to use this tool?
How does all that tell the reader about the proprietry file formats
you mention?
As for my harsh comment, Kernel Traffic used to be brilliant, I'd
look forward to an issue coming out, this is probably just a bad
patch but if something sucks people should say it sucks rather than
just ignoring it like you suggest. If Zack wants to ignore my feedback
he can, harsh feedback is better than none at all.
Well, as Zack has pointed out
Well, as Zack has pointed out often enough, kernel traffic shows _his_ view of the lkml. Those who want more are to read the list themselves. Personally, I think including this HOWTO is a Good Thing(TM), because it allows people to see what BK does and how. Ans let's not forget, _noone_ is forced to use bk since Linux still gives out the tar archives and patches as he used to, and he will do so further on (or someone else will).
If BK really becomes an obstacle for kernel development, it won't be used anymore.
To see parallels between the minix situation ten years ago and the bk situation now borders on paranoia. If anyobody can provide with an open source solution that does all that Linus wants from BK, it would be happily adopted. Since this is not the case, BK is better than nothing.
Regards,
H.
PS: I am not yet registered, but I can be reached by my private email address hollow@tzi.de
What were the problems Minix
What were the problems Minix had? I've heard there were licencing problems, but what else for those who don't know. How do they relate to the Linux/BK situation?
As I understand it before Linus started using BK anybody could send in a normal patch for him to consider. Now that Linus is using BK, anybody can still send him normal patches, but those who use BK can also send BK changesets. What's the problem? It doesn't seem much different to Linus using a closed source text editor, the resulting code is still GPL'd and submissions are still allowed by anyone.
If Linus was to ever start refusing anything but BK changesets there would and should be storms of protest. However I can't see that happending.
Hopefully all of this discussion of SCM might promote interest in improving the GPL'd SCM tools.