Domain: theaimsgroup.com
Stories and comments across the archive that link to theaimsgroup.com.
Comments · 481
-
Re:Alphas are great, but...Arguing over the internet is like being in the Special Olympics: win or lose, you are still retarded.
http://marc.theaimsgroup.com/?l=openbsd-misc&m=10
3 981552306112&w=2 -
Recent discussion on lkml
gcc optimzations for the kernel were discussed recently on this thread
-
Re:Funny printk in die_if_kernel for sparc64
Nah, I like the cow better. Slash won't let me post it, so here's a link.
-
Burning PrintersThe full story on Burning Printers can be seen here
And apparently, originally it was a very legitimate error message.
Another bit of lore and trivia for the mad scientist to know
;-)
-
Re:JBoss as well.
To JBoss's credit, they do offer a basic manual for free.
The JBoss 3 Getting Started manual is not something to give any credit for. It is outdated, you have only to get a couple paragraphs into the manual before it tells you something that is just plain wrong anymore. The person who was writing the manual, Andreas Schaeffer, left the JBoss Group and was recently kicked off the JBoss project at Sourceforge (they did have a good reason for doing so). The link from JBoss.org goes to draft 3 of the Getting started manual, even though draft 4 has been out since august (you just have to search for it - but it still contains assorted incorrect information and bad grammar).
Andreas did a lot of work on the Getting Started Manual, but I don't think he is a native english speaker. The manual looks like it was passed through a spell checker, but the grammar is so bad at spots, you can not tell what is being said. JBoss Group claims that it has high quality documentation that has been written by the authors of JBoss and edited by professional editors... If the getting started manual is any indication of the professional quality of JBoss documentation -- and why shouldn't it be? It is the first documentation anybody is likely to see when they first investigate JBoss, this is where they would put their best foot forward -- I see no reason to buy any of it. -
Re:JBoss as well.
To JBoss's credit, they do offer a basic manual for free.
The JBoss 3 Getting Started manual is not something to give any credit for. It is outdated, you have only to get a couple paragraphs into the manual before it tells you something that is just plain wrong anymore. The person who was writing the manual, Andreas Schaeffer, left the JBoss Group and was recently kicked off the JBoss project at Sourceforge (they did have a good reason for doing so). The link from JBoss.org goes to draft 3 of the Getting started manual, even though draft 4 has been out since august (you just have to search for it - but it still contains assorted incorrect information and bad grammar).
Andreas did a lot of work on the Getting Started Manual, but I don't think he is a native english speaker. The manual looks like it was passed through a spell checker, but the grammar is so bad at spots, you can not tell what is being said. JBoss Group claims that it has high quality documentation that has been written by the authors of JBoss and edited by professional editors... If the getting started manual is any indication of the professional quality of JBoss documentation -- and why shouldn't it be? It is the first documentation anybody is likely to see when they first investigate JBoss, this is where they would put their best foot forward -- I see no reason to buy any of it. -
Al Viro hates it !I didn't look at the source myself, but here is a quote from Al Viro who did (and I find he has good taste):
Damn you. That thread got me to download subversion source and read it - mistake I won't repeat any time soon. I've spent several months wading through fairly disgusting code - block device drivers are not pretty, ditto for devfs. I had more than once found myself grabbing Lovecraft to read something that would be less nightmare-inducing. But _THAT_ takes the fscking cake - I don't _care_ what Larry (or anybody else for that matter) does to people who had excreted that code. No, wait - I _do_ care. I want video of the... event. I don't use BK, but you can be damn sure that I won't touch SVN. Ever.
found on The Linux Kernel Mailing-List
-
Re:difference
If you read the exhaustive thread on the topic. The idea is not to "block spam", but to slow down/cause "harm" to the open relays, in the hopes that the only way these oblivious people who have open relays will realize that they do, is when i.e. your server craps out with "disk full" errors, or the like.
-
the code in question
here's what we're talking about.
-
Re:Patent issues?
In this e-mail Robert Barr from Cisco answers to the main developer of keepalived that Cisco will not attack VRRP implementations unless a patent claim is asserted against Cisco. Unfortunately he also states that he expects that IBM's stance on this is the opposite of Cisco's.
-
Re:Similar problem with Adaptec
Really, try real research, not this google crap.
Since you asked so nicely... -
Theo's Conversation
This story was posted in the BSD section, I wrote something there. Didn't start enough of a flame war, so I'll repost it. Before flaming, make sure you read the email thread.
OK, I'm karma capped, lets some good ol' flaming start...
Theo de Raadt: (calls up Sun) Hello, I demand some documentation.
Sun Guy: Who the f*** are you?
TdR: I'm Theo de Raadt.
SG: Which Theo de Raadt?
TdR: The one that is incredibly smart and productive and gets real pissy when I don't get my way; the one that forked OpenBSD because the NetBSD folks didn't like how pissy I got and drove users away.
SG: Oh that one. What documentation do you demand because you somehow infer a right to having?
TdR: On the UltraSparc III processor.
SG: Oh, the one that you spent no R & D money on, that you spent no manufacturing money on, but you feel you have an absolute right to have it and if you don't get it you get pissy?
TdR: Yeah, thats the one.
SG: OK, here is our link.
TdR: This isn't enough. I want more.
SG: What other documentation are you demanding?
TdR: I don't know. It is your job to figure out what documentation I don't have and to get it to me when I demand it.
SG: If you don't even know what to ask for, how are you demanding more?
TdR: Those other guys get more.
SG: Which guys?
TdR: The Linux guys.
SG: You mean the ones that we kind of work with because we have an Intel distro and we should really appease the guys that kind of put it together? The OS that we might try to sell some software on?
TdR: Yeah, I want what they have. I deserve it.
SG: Why?
TdR: Because I want it to make a server.
SG: Using what OS?
TdR: A free one, that will put no money in your pocket for OS licenses, no money for support, that will most likely not sell any Sun software because it usually runs as a fairly stripped down firewall box, and won't even sell any of your real expensive hardware where you make the real money from since we don't support SMP. Since you lost a lot of money when the dot-com bubble burst, and your stock is now close to historic lows and have had a couple rounds of layoffs, you must be real enthused about doing some work which probably won't get your company any money at all?
SG: Ahh, so you demand we get some internal engineers for you who luckily will be really eager to stop their real work fending off fierce competition from IBM Windows HP and Linux, gather all our UltraSparc-III stuff for you, run it through our lawyers who luckily enough will drop all work involving our lawsuits about Microsoft and Java (and possible shareholder and wrongful termination lawsuits) sanitize it for you because from your reputation for getting pissy over things (witness ipf) you won't take kindly to an NDA and rush it to you on your schedule not ours.
TdR: If you don't, I'll get pissy. Yes, and make sure you get that NDA stuff out. We're opensource, and we don't like NDAs, and since we're always right your NDAs should go away because we say so.
I know why Theo would want this, but I can't see the Sun guys dropping everything and making this their number one priority. Though childish, if I was a Sun person, I'd release this stuff first to FreeBSD and NetBSD, knowing it would eventually trickle down to OpenBSD, just to piss off Theo. -
EXT3 may be broken
Here is a link with some info about it. Now much though...
But here where I work one guy tried 2.4.20 on his Mandrake 9.0 (I cannot confirm that he did everything right though), but his / partition got completely corrupted. Same thing after fresh install and new kernel install. -
Re:Hmmm
Did you read the mailing list? Obviously not.
-
Theo's diplomacyTheo de Raadt writes:
> PS No, I don't work for Sun, and I'm not in bed with them. But
> working for a LARGE company has taught me many things about
> Bureaucracy, and two of those are: 1) Assume a lack of action before
> an action (i.e., things tend *not* to happen in a bureaucracy), and 2)
> if you can, pointing to a thing is almost always better than asking
> for an unknown.
No, you misunderstand. We've tried so hard; that is no excuse.
Perhaps this will teach them to be less opaque.
I think there are some times when Theo's style is dead on, like with the ipf filter. However, in this case it may not be the most constructive way to effect a change. -
Re:Newer major versions often drop features
Stop trolling. ``all his other software to support djbdns'' consists of one package: daemontools
I said "other software," not "other packages," didn't I? Daemontools and djbdns installed a lot of programs, inclunding svscan and supervise, log and all the programs, directories and rc files to run and manage them; not to mention /package, DJB's personal global namespace.And if you felt like setting up djbdns by hand,
And deny myself the right to post questions to DJB's mailing lists about running his software The Wrong Way. Which I didn't.Unless, of course, you don't care if your services stay up without you constantly watching them.
My home machine still runs inetd, fer Chrissake, and I've never woken up to my machine without it. I've also used xinetd and daemon on 'real' servers happily enough.Patches are allowed and encourged.
The right ones, anyway.Stop trolling..... The rest of your post is complete FUD....
You're the strident one. Hell, you even declined to quote or reply to my statement of observation that BIND 9 is almost as fast as dnscache, but if you started arguing facts, that wouldn't be fud, I mean, fun anymore, would it? And do consider that remedial English course. I said, "since I cannot use djbdns in the spirit of Bernstein's license, I will not use it." If you like his terms, by all means, go to it. That's not FUD, that's one man voting with his dselect. -
Re:PahAccording to Todd Miller, yes, but.... Under OpenBSD BIND is chrooted to
/var/named, which means its potential for damage if infected is highly limited.Those who are stuck with BIND 4 for legacy reasons or whatnot are probably best off switching over to a chroot'd configuration - it's all very easy and the functionality is already built in.
-
Evolution on Windows...In the short term, when using Windows, the most stable and simplest thing you can do is use a VNC viewer pointed at a *nix box that has Evolution on it. Otherwise, take a look at these efforts to get Gnome and other programs ported using Cygwin;
http://homepage.ntlworld.com/steven.obrien2/index
. htmlhttp://marc.theaimsgroup.com/?l=gnome&m=101015707
5 21446&w=2http://www.geocities.co.jp/SiliconValley/1596/en/
c ygwin.html
Unfortunately, I don't see any new efforts at a port of Evolution to Windows, but as it improves folks will start to demand it everywhere they are.
Mac OSX users are much more lucky -- they can get Evolution right now. Fink lists it as a ported app.
It would be nice to have a Windows CD with all X apps so that folks can see that *nix systems aren't usually text-based or some ugly form of CDE. Till then, I've found the boot CD and full Debian distributionKnoppix to be an ideal introduction. Blew the socks off of a admin I showed it to who didn't know it was possible, and impressed others who like the idea of Linux but can't be bothered with actually learning anything (kids, job, wife, do the math).
-
Re:Whats critical for me...
-
Hmmm
It's really great that the number 1 portion of Andreas Pour's KGX will be released!
Now nothing will stop KGX from killing that monopolist M$ on the desktop!
-
Re:Disappointed with MandrakeSoftBugzilla is sitll not the main setup yet... There was a lot of discussion about this after the release in this thread:
http://marc.theaimsgroup.com/?l=mandrake-cooker&m= 103297553303638&w=2It looks like they are going to do something different and that it won't be the mailing list. But it hasn't been implemented yet.
-
Re:Hmmm...The funny thing is that Linus recently said:
And I personally refuse to use inferior tools because of ideology. In fact, I will go as far as saying that making excuses for bad tools due to ideology is _stupid_, and people who do that think with their gonads, not their brains.
I'd argue that for a long time, minix was better than linux, simply because it was more complete.
The only thing Linux had going for it was that it had a better license, which is ideological.Oh well. He was right to create linux, he (and others) wanted a unix-like OS that they could run on their home PCs, but I think he's forgotten some of his ideals.
-
Re:carefull...Quote from site
Thanks.
The MD5 checksums for the official and portable tarballs are provided in the announcement here. -
Re:point
this is what all of bitkeeper's advocates, including it's creator, Larry McVoy
Actually, I *read* the thread, and Larry was attempting to claim that everyone should stay away from free version-control systems, and that he felt it was necessary to impede their development in any way possible.
His reasoning was essentially that someone could make a free bitkeeper clone which would be "good enough" to draw bitkeeper users away and bankrupt him, but that (because they would be unpaid/amateur/lazy/not Larry McVoy) they would be unable to acheive bk's high level of quality, the sun would fall out of the sky, the seas would
boil, etc.
One such message is here, but there were a number of variations on the theme that were posted.
Daniel -
Re:it looks like a Linux problem to me
There are plenty of huge open source projects, and they work fine with CVS. GNU Hurd is being developed with CVS. BSD is. To me, the real question is: what is going wrong with Linux kernel development that CVS is not sufficient?
Neither have the magnitude of Developers or incoming patches that the Linux kernel has- *BSD have very small development teams. HURD's developer team is slightly larger, but still nowhere as large.
Here's an archive of the recently-set-up bk-commits-head mailing list, which shows patchsets sent through the bk 2.5 development tree alone. -
Re:point
Software with non-restrictive licenses should be used for important free software projects even when it is not seemingly the best tool for the job.
Try telling them this; The kernel developers would laugh in your face. They've said before (Linus Especially) that they're not going to use an inferior tool just because it's free. As long as it doesn't hurt them, they'll use what they consider the best tool for the job.
A license like this makes things harder for someone who wants to hack on the kernel but who is prohibited by BitKeeper from getting the source the way the rest of the kernel team does.
Not really. like has been pointed out many many times on lkml, you don't need to even touch BK to be involved in kernel development.
As linus said in one of his posts to lkml a while back, "Or just go on and ignore the fact that some people are using BK - you don't actually have to ever even know.". The kernel team using bk doesn't hurt on anyone's ability to develop the kernel. -
Re:Simple Solution
Here's a handful of links to kernel archive mirrors discussing subversion. There current attitude of kernel developers is that subversion is nowhere near mature enough to replace bk for kernel use yet. once it is, people will happily switch.
So, for the time being, live with them using BK, and know that you don't have to use it at all to help with kernel development. -
Re:Simple Solution
Here's a handful of links to kernel archive mirrors discussing subversion. There current attitude of kernel developers is that subversion is nowhere near mature enough to replace bk for kernel use yet. once it is, people will happily switch.
So, for the time being, live with them using BK, and know that you don't have to use it at all to help with kernel development. -
Re:Simple Solution
Here's a handful of links to kernel archive mirrors discussing subversion. There current attitude of kernel developers is that subversion is nowhere near mature enough to replace bk for kernel use yet. once it is, people will happily switch.
So, for the time being, live with them using BK, and know that you don't have to use it at all to help with kernel development. -
RMS kneejerkRMS: "The new restrictions on Bitkeeper, saying that people who contribute to CVS or Subversion and even companies that distribute them cannot even run Bitkeeper, have sparked outrage."
As far as I know from reading the first slashdot story, the Bitkeeper folks are not saying that "companies that distribute [subversion, et al] cannot even run Bitkeeper." Rather, it's only programmers who are actively participating in the development of Bitkeeper replacements that cannot take advantage of the free license. In the words of Larry McVey speaking on behalf ob Bitmover,Our position is clear, it's not unreasonable, it affects very few kernel developers, and it doesn't even make those developers any worse off than they were before we showed up. All we are saying is that you don't get to use our tools if you are trying to rewrite our tools.
In my opinion, that makes the situation considerably less imperative. Sure, it's a real wrench in the works, but it's not as bad as it's made out to be -- BK is not preventing Redhat, Suse, Mandrake (et al) employees from using BitKeeper, only those who actively develop Subversion or arch.
Flame away. -
OpenBSD not affected:for those of you who read
/. instead of the mailing lists for your OpenBSD news, OpenBSD is not affectedFrom: Todd C. Miller
To: mr grip
Cc: misc@
Subject: Re: sendmail trojan - were stable or current affected?In message so spake "mr grip" (jhonold):
> does anybody know if either tree in the last couple months had trojaned code
> in it, exploiting make builders?Not affected. When I committed sendmail 8.12.6 the tarball I fetched
was not the trojaned one. Even if it had been we probably would
not have been affected since we don't use sendmail's build system
(which is where the trojan was apparently inserted).- todd
-
Re:What World Do These People Live In?
More notice for dropping support? Isn't there stated policy that they support only the current release and the previous release? Look at the fancy ASCII map of their release schedule. It clearly shows that only two releases are maintained at one time. I've been using OpenBSD since 2.9, and I was always aware of their support scheme. Where have you been?
Do you assume that they have the resources to support older releases just because it is an inconvenience for your to upgrade? They are offering you a really great OS for free. They work really hard to make sure that it is the best it can be. And what I like most about the OpenBSD team is that they really take a stand for freedom issues in software (read Theo's stance on the Sun ECC code being included in OpenSSL in this message, or check out the entire thread).
Give these guys a break. You had 6 months to test 3.1 and upgrade your boxes from 3.0. If you don't like their policy, use something else. As someone said over a deadly.org, if you want support for older releases, pay someone to provide patches for your system. Whatever you decide to do, stop complaining about something they give away for free. -
Re:What World Do These People Live In?
More notice for dropping support? Isn't there stated policy that they support only the current release and the previous release? Look at the fancy ASCII map of their release schedule. It clearly shows that only two releases are maintained at one time. I've been using OpenBSD since 2.9, and I was always aware of their support scheme. Where have you been?
Do you assume that they have the resources to support older releases just because it is an inconvenience for your to upgrade? They are offering you a really great OS for free. They work really hard to make sure that it is the best it can be. And what I like most about the OpenBSD team is that they really take a stand for freedom issues in software (read Theo's stance on the Sun ECC code being included in OpenSSL in this message, or check out the entire thread).
Give these guys a break. You had 6 months to test 3.1 and upgrade your boxes from 3.0. If you don't like their policy, use something else. As someone said over a deadly.org, if you want support for older releases, pay someone to provide patches for your system. Whatever you decide to do, stop complaining about something they give away for free. -
Re:Prices for BitKeeper-removed from Google cache?
Normally, docs pulled down by Nazis are available via Google cache, at least for a while. I wondered why the list wasn't available, when I ran across this blurb in a post to lkml:
[lm]: "I also walked away from Google when there were three people there (the full story is that I din't [sic] know it was $60M at Cobalt, I was guessing more like $5-12M million, but I was fully aware of what I was giving up at Google and it was certainly more, at least it is in my opinion)."[/lm]
I guess he didn't give up his contacts there, to make Google cache docs disappear so quickly...
Also, despite his 'SlashDot kiddies' comment, he follows this blog like a lovesick teenager. You'll note that Xaxxon posted his comment about the price list at 10:18AM, and Xaxxon posted that he had taken it down by 11:03. Pretty quick work by 'Larry the Lurker'. I hope he doesn't wear out his 'reload' button. -
Re:Since when?Since when does ppl acutally read the EULA?
I know Theo de Raadt does, which is why I stick with OpenBSD. He's hard-nosed (some say obnoxious), but principled like RMS. So even recently he called for a fork of OpenSSL, since they accepted Sun code which has some strings attached. See here.
-
Linus does not seem too concerned
http://marc.theaimsgroup.com/?l=linux-kernel&m=1 03 388364206058&w=2
In article <1033861827.4441.31.camel@irongate.swansea.linux.o rg.uk>,
Alan Cox <alan@xxxxx> wrote:
>
>Linus used to do about a patch every 2 days. Nowdays its a lot slower. I
>put that down to buttkeeper
Don't be silly, Alan.
I don't do any pre-patches or daily patches any more, because it's all
automated. There are several snapshot bots that give you patches a lot
more often than "every 2 days". You don't need BK to use it, it's there
in the good old diff format.
(I haven't checked whether the auto-patches do a good job of doing
changelogs too, but since all the changelogs I generate for the _real_
releases are also automated and I make the tools I use to generate them
available, that's certainly not anything fundamental).
So yes, you can "put it down to bitkeeper" in the sense that it's
because of the automation that BK allows that I don't _need_ to
personally do pre-patches any more.
"Big boo-hoo, bitkeeper is evil, and Linus doesn't manually do any more
what BK plus a few scripts does better for us automatically."
Linus
-
Re:McVoy just killed BKIf you're using BK for source management you have to be looking over your sholder and worrying what proclamation McVoy will issue next that might force you to throw out all versions in your tree currently and move to an alternative product.
Wow, this is FUD worthy of Microsoft.
Go read the fscking links. All it says is that you can't use BitKeeper to work on competing products. Can you use BitKeeper to work on The GIMP? Sure. Can you use BitKeeper to work on KDE? Sure. Can you use BitKeeper to work on Subversion? No.
Do you honestly think it's McVoy's goal to kill off free software? If so, why does he say in his mail that
we're a business which happens to be committed to helping the kernel team because we think that the kernel is vital to the world at large. Helping the kernel absolutely does not translate to helping people who happen to be our competitors.
Come on, people. If they really hated free software, they wouldn't be doing this. Of course, now is the spot where people will chime in saying "they're just making us use it so they can control the code and lock us in." Wrong. I haven't used BitKeeper, but I'll bet that you can still get the source code out of it. I don't think it will ever prohibit you from extracting the current source tree - if it does, well, that's the point at which Linus should abandon it.That having been said, it does appear from this mail that McVoy has a personal disagreement with Ben Collins. (See the relevant text about 'netwinder') If so, a EULA is a poor forum in which to take action for his grievances. It does NOT, however, mean that he is any more wrong for doing so. He wants to make money. There's nothing wrong with that. The FSF may have a truly noble cause, but until there's such a thing as Open Source Food, and Free-As-In-Beer-And-Speech housing, people will still need money.
Now is the chance for the community to put live up to its hype. We've always said that we don't need to badmouth MS, we can just come up with something better. Go ahead! Make Subversion better than BitKeeper. Make it so that everyone who uses BitKeeper will be pounding your doors down trying to get Subversion. This isn't Windows we're talking about here - it's a revision control prorgam that's used mainly by clueful people. So make Subversion better, and put BitMover out of business, and then you'll have won.
-
Re:McVoy just killed BKIf you're using BK for source management you have to be looking over your sholder and worrying what proclamation McVoy will issue next that might force you to throw out all versions in your tree currently and move to an alternative product.
Wow, this is FUD worthy of Microsoft.
Go read the fscking links. All it says is that you can't use BitKeeper to work on competing products. Can you use BitKeeper to work on The GIMP? Sure. Can you use BitKeeper to work on KDE? Sure. Can you use BitKeeper to work on Subversion? No.
Do you honestly think it's McVoy's goal to kill off free software? If so, why does he say in his mail that
we're a business which happens to be committed to helping the kernel team because we think that the kernel is vital to the world at large. Helping the kernel absolutely does not translate to helping people who happen to be our competitors.
Come on, people. If they really hated free software, they wouldn't be doing this. Of course, now is the spot where people will chime in saying "they're just making us use it so they can control the code and lock us in." Wrong. I haven't used BitKeeper, but I'll bet that you can still get the source code out of it. I don't think it will ever prohibit you from extracting the current source tree - if it does, well, that's the point at which Linus should abandon it.That having been said, it does appear from this mail that McVoy has a personal disagreement with Ben Collins. (See the relevant text about 'netwinder') If so, a EULA is a poor forum in which to take action for his grievances. It does NOT, however, mean that he is any more wrong for doing so. He wants to make money. There's nothing wrong with that. The FSF may have a truly noble cause, but until there's such a thing as Open Source Food, and Free-As-In-Beer-And-Speech housing, people will still need money.
Now is the chance for the community to put live up to its hype. We've always said that we don't need to badmouth MS, we can just come up with something better. Go ahead! Make Subversion better than BitKeeper. Make it so that everyone who uses BitKeeper will be pounding your doors down trying to get Subversion. This isn't Windows we're talking about here - it's a revision control prorgam that's used mainly by clueful people. So make Subversion better, and put BitMover out of business, and then you'll have won.
-
Re:Alan Cox?
-
Re:Alan Cox?
-
Re:Alan Cox?
-
Please see Larry's comments (and responses)
I believe the intent of "Col. Klink (retired)" was to bring this to a wider audience, but there are several points that need to be reiterated.
1) "In fact you can't use BitKeeper if you OR your company have anything to do with competing software."
The above applies to /free/ use only. You are still welcome to purchase a commercial license from BitMover. What Larry has said "makes sense" from a survival/profit (i.e. capitalist) point of view: "you simply don't get to use our product -- which we provide for free -- to put our company out of business."
Furthermore, Larry has demonstrated that even if you /don't/ use BK, accessing changes and patches should be no more difficult than prior to Linus's trial/adoption of BK.
2) It has been made very clear by several of the core developers that accessibility to Linus's merges has been made much easier since his trial/adoption of BK. See here, here, and here.
3) This is hardly a "new EULA."
Please see the thread at http://marc.theaimsgroup.com/?l=linux-kernel&m=103 389686711292&w=2, or subscribe to linux-kernel at vger.kernel.org for updates. -
Please see Larry's comments (and responses)
I believe the intent of "Col. Klink (retired)" was to bring this to a wider audience, but there are several points that need to be reiterated.
1) "In fact you can't use BitKeeper if you OR your company have anything to do with competing software."
The above applies to /free/ use only. You are still welcome to purchase a commercial license from BitMover. What Larry has said "makes sense" from a survival/profit (i.e. capitalist) point of view: "you simply don't get to use our product -- which we provide for free -- to put our company out of business."
Furthermore, Larry has demonstrated that even if you /don't/ use BK, accessing changes and patches should be no more difficult than prior to Linus's trial/adoption of BK.
2) It has been made very clear by several of the core developers that accessibility to Linus's merges has been made much easier since his trial/adoption of BK. See here, here, and here.
3) This is hardly a "new EULA."
Please see the thread at http://marc.theaimsgroup.com/?l=linux-kernel&m=103 389686711292&w=2, or subscribe to linux-kernel at vger.kernel.org for updates. -
Please see Larry's comments (and responses)
I believe the intent of "Col. Klink (retired)" was to bring this to a wider audience, but there are several points that need to be reiterated.
1) "In fact you can't use BitKeeper if you OR your company have anything to do with competing software."
The above applies to /free/ use only. You are still welcome to purchase a commercial license from BitMover. What Larry has said "makes sense" from a survival/profit (i.e. capitalist) point of view: "you simply don't get to use our product -- which we provide for free -- to put our company out of business."
Furthermore, Larry has demonstrated that even if you /don't/ use BK, accessing changes and patches should be no more difficult than prior to Linus's trial/adoption of BK.
2) It has been made very clear by several of the core developers that accessibility to Linus's merges has been made much easier since his trial/adoption of BK. See here, here, and here.
3) This is hardly a "new EULA."
Please see the thread at http://marc.theaimsgroup.com/?l=linux-kernel&m=103 389686711292&w=2, or subscribe to linux-kernel at vger.kernel.org for updates. -
Please see Larry's comments (and responses)
I believe the intent of "Col. Klink (retired)" was to bring this to a wider audience, but there are several points that need to be reiterated.
1) "In fact you can't use BitKeeper if you OR your company have anything to do with competing software."
The above applies to /free/ use only. You are still welcome to purchase a commercial license from BitMover. What Larry has said "makes sense" from a survival/profit (i.e. capitalist) point of view: "you simply don't get to use our product -- which we provide for free -- to put our company out of business."
Furthermore, Larry has demonstrated that even if you /don't/ use BK, accessing changes and patches should be no more difficult than prior to Linus's trial/adoption of BK.
2) It has been made very clear by several of the core developers that accessibility to Linus's merges has been made much easier since his trial/adoption of BK. See here, here, and here.
3) This is hardly a "new EULA."
Please see the thread at http://marc.theaimsgroup.com/?l=linux-kernel&m=103 389686711292&w=2, or subscribe to linux-kernel at vger.kernel.org for updates. -
Undeleting files under reiserfsAs chance would have it, I had to perform this task for one of my clients at the weekend as they had just deleted their entire active database (doh!). After a load of research, I found that the best resources are to be found in the reiserfs mailing list.
The key post was this one which pointed me at using:-
reiserfsck --rebuild-tree -S -l rebuild.log
/dev/yourdeviceVery scary. Had to boot into a rescue system off CD first, mount HDD RO, then get enough tools to be able to backup the HDD to a remote box. Unmount disk and then run reiserfsck. Pray for a bit. Got all the db files back (and because they where in a directory that was deleted, they had all the correct names as well (once I'd found the directory)).
There was some minor file-system corruption for files that had been written frequently, but this was taken care of by restoring the previous backup and checking everything else from the RPM db. So, all-in-all not an experience that you would want to do on a daily basis, but definately worth it to restore 2 months of lost work (why oh why don't people use backups?).
As far as kernel hooks for undeleting data, the mailing list link above contains several discussions about this, but the general feeling seems to be that it is possible but Linus doesn't want it (see here.
-
Undeleting files under reiserfsAs chance would have it, I had to perform this task for one of my clients at the weekend as they had just deleted their entire active database (doh!). After a load of research, I found that the best resources are to be found in the reiserfs mailing list.
The key post was this one which pointed me at using:-
reiserfsck --rebuild-tree -S -l rebuild.log
/dev/yourdeviceVery scary. Had to boot into a rescue system off CD first, mount HDD RO, then get enough tools to be able to backup the HDD to a remote box. Unmount disk and then run reiserfsck. Pray for a bit. Got all the db files back (and because they where in a directory that was deleted, they had all the correct names as well (once I'd found the directory)).
There was some minor file-system corruption for files that had been written frequently, but this was taken care of by restoring the previous backup and checking everything else from the RPM db. So, all-in-all not an experience that you would want to do on a daily basis, but definately worth it to restore 2 months of lost work (why oh why don't people use backups?).
As far as kernel hooks for undeleting data, the mailing list link above contains several discussions about this, but the general feeling seems to be that it is possible but Linus doesn't want it (see here.
-
Undeleting files under reiserfsAs chance would have it, I had to perform this task for one of my clients at the weekend as they had just deleted their entire active database (doh!). After a load of research, I found that the best resources are to be found in the reiserfs mailing list.
The key post was this one which pointed me at using:-
reiserfsck --rebuild-tree -S -l rebuild.log
/dev/yourdeviceVery scary. Had to boot into a rescue system off CD first, mount HDD RO, then get enough tools to be able to backup the HDD to a remote box. Unmount disk and then run reiserfsck. Pray for a bit. Got all the db files back (and because they where in a directory that was deleted, they had all the correct names as well (once I'd found the directory)).
There was some minor file-system corruption for files that had been written frequently, but this was taken care of by restoring the previous backup and checking everything else from the RPM db. So, all-in-all not an experience that you would want to do on a daily basis, but definately worth it to restore 2 months of lost work (why oh why don't people use backups?).
As far as kernel hooks for undeleting data, the mailing list link above contains several discussions about this, but the general feeling seems to be that it is possible but Linus doesn't want it (see here.
-
no need to fork OpenSSL
In the cryptography mailing list, it appears that Theo may not need to declare jihad on licenses he doesn't like.
According to Ulf Möller there will be a patch made before the next release to isolate the ECC code in case of patent concerns. The ECC code can be included or excluded based on a configure flag like the present RC5 and IDEA algorithms which are still patented in various parts of the world.
Apparently the patent claim is an additional optional provision that companies can use the Sun code under a truce against lawsuits if they agree to not sue about ECC patent infrigement either. -
no need to fork OpenSSL
In the cryptography mailing list, it appears that Theo may not need to declare jihad on licenses he doesn't like.
According to Ulf Möller there will be a patch made before the next release to isolate the ECC code in case of patent concerns. The ECC code can be included or excluded based on a configure flag like the present RC5 and IDEA algorithms which are still patented in various parts of the world.
Apparently the patent claim is an additional optional provision that companies can use the Sun code under a truce against lawsuits if they agree to not sue about ECC patent infrigement either.