Re: BitKeeper Cont. [was Re: My projects are gone (fwd)]
Hi Oded! I love it that people decide the victim is the one responsible. Let me explain some things: 1. I was offered to use BitKeeper and bkbits.net at terms I could accept (i.e: I sent the patchsets to openlogging.org, don't see the source (even though the site says otherwise), etc.). I happily used it for the while. Then the terms of BitKeeper were changed (without consulting me) to such that I cannot accept. From out of no where what I had to put in the repositories could no longer be proprietary. I could not accept this both ideologically and practically (I did put some copyrighted board layouts in my repository for safe keeping), so I voiced my opinion against it. I can write whatever I want in my Advogato diary. Granted, the post to bitkeeper-users was off-topic, and may have been trollish. I did not know it was off-topic at the time. Furthermore, I believed I did Larry a favour by opening the bitkeeper-license mailing list. 2. I started the Better SCM initiative after I discovered how flame-bait and irrational Larry McVoy is. (if you want I can send you a very insulting letter he sent me). I am trying to free BK or outcompete it (preferably the first option). And I now decided that I am pro BK not against it, even though I would not recommend anyone to use it until Larry loses most of his attitude. (which IMHO will only happen once he GPLs BitKeeper). 3. Removing the data without my explicit permission is something I consider a malicious misplacement of information. The data was _mine_ intellectual property. Luckily, it was not lost, but it may have had I been less careful. You be the judge if Larry was the victim here. Granted, I was not the most righteous man. But your free user is a 100% customer. His data is sacred. I will not use bkbits.net again, and will go on with the Better SCM movement, which will mention BitKeeper, but will specifically mention Mr. McVoy as its greatest flaw. Note that there isn't a single person on Earth who is more pro-business and pro-free competition than I am. But Larry, while being an honest entrepreneur, is so ridden with irrationality, that I am completely appaled by him. I even like the Microsoft people better than I do him, because at least they don't pose themselves as proponents of freedom in software, while obviously being the opposite. If you think I'm alone here, you should read the Linux Kernel Mailing List. At least half of its members would agree with everything I say here. Right now I'm learning Aegis, hoping it will be half as decent as BitKeeper is, and am impressed by the positive responces I received from its user community and its project manager, Peter Miller. Regards, Shlomi Fish There is no IGLU Cabal! The entire Cabal Protocols were managed using BitKeeper. You deduce what happened next. -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] Let's suppose you have a table with 2^n cups... Wait a second - is n a natural number? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On Thu, 26 Sep 2002, Muli Ben-Yehuda wrote: shape or form. Why don't you use the vendor's kernels? For production use, that's definitely the safest bet. That is completely untrue, and also missleading to the whole community reading this thread. It is a sad fact that for example, RedHat kernels have a zillion of badly tested or even not that patches, which Linus and the Linux kernel development team would never insert in the kernel just like that. Not only that they are not *stable*, they are less stable than any pre kernel. So, on contrare, some of the 2.4.x-pre?-ac? kernels I've installed are the most stable kernels Linux ever had, mainly since the -ac codebase patches include the FreeBSD like VM. Actually, TAU mail services are running on two machines using 2.4.18-pre3-ac2, being very very stable for quite a long time. And I have asked this question *BECAUSE* I have a problem with an appliance using RedHat 7.2, and with the Linux kernel supplied by RedCrack. --Ariel -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foohttp://syscalltrack.sf.net/ Quis custodes ipsos custodiet? -- Ariel Biener e-mail: [EMAIL PROTECTED] PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On Thu, Sep 26, 2002, Ariel Biener wrote about Re: linux 2.4.20-pre?-ac? kernels: That is completely untrue, and also missleading to the whole community reading this thread. It is a sad fact that for example, RedHat kernels have a zillion of badly tested or even not that patches, which Linus and the Linux kernel development team would never insert in the kernel just like that. Not only that they are not *stable*, they are less stable than any pre kernel. People, please, when you trash Red-Hat in this list, please at least specify what kind of experience you have with them. People have been saying things here that are in *COMPLETE* contradiction to my 5-year experience with various versions of Redhat. I suspect that some of the people trashing Red- Hat are not actually using it, and are just assuming things. In the last couple of years I've been using Redhat 7.* extensively both at home and at work. I've never encountered any problems with gcc 2.96 (certainly not with the Redhat 7.1 and later versions), but its greatly improved C++ support and other improvements over 2.95 were important to me. In all this time, I only encountered one buggy Redhat kernel, and that bug wasn't all that serious (reiserfs filesystems could not be umounted). In fact, I found Redhat's kernels to be very stable. And I have asked this question *BECAUSE* I have a problem with an appliance using RedHat 7.2, and with the Linux kernel supplied by RedCrack. I guess you really love Red-Hat :) Please don't learn manners from Linus :( Referring to people you don't agree with as drug addicts is not a very nice thing... Anyway, are you using the *latest* update kernel for Redhat 7.2? -- Nadav Har'El|Thursday, Sep 26 2002, 20 Tishri 5763 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |I am thinking about a new signature. Stay http://nadav.harel.org.il |tuned. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On Thu, Sep 26, 2002 at 12:58:08PM +0300, Ariel Biener wrote: On Thu, 26 Sep 2002, Muli Ben-Yehuda wrote: shape or form. Why don't you use the vendor's kernels? For production use, that's definitely the safest bet. That is completely untrue, and also missleading to the whole community reading this thread. It is a sad fact that for example, RedHat kernels have a zillion of badly tested or even not that patches, which Linus and the Linux kernel development team would never insert in the kernel just like that. Sorry, you're dead wrong. Redhat is a distribution. Redhat has a certain commitment to the people who *pay* them, to ensure a certain standard of quality. That means that Redhat TEST their kernels and do QUALITY ASSURANCE on them. Can you say the same things about Linus kernels? (you can't). Can you say the same thing about Marcelo's kernels (maybe, probbly, we don't know). Can you say the same thing about AC's kernels? (not lately). You asked about a production server. Seems to me you don't know what production server means. Not only that they are not *stable*, they are less stable than any pre kernel. ??? Please back this assertion up with version numbers and bugs discovered. Otherwise, you're just spouting at the mouth. So, on contrare, some of the 2.4.x-pre?-ac? kernels I've installed are the most stable kernels Linux ever had, mainly since the -ac codebase patches include the FreeBSD like VM. Actually, TAU mail services are running on two machines using 2.4.18-pre3-ac2, being very very stable for quite a long time. To quote Alan Cox, at Message-Id: [EMAIL PROTECTED] Date: Sun, 11 Aug 2002 20:10:04 -0400 (EDT) From: Alan Cox [EMAIL PROTECTED] X-Mailer: ELM [version 2.5 PL6] To: [EMAIL PROTECTED] Subject: Linux 2.4.20-pre1-ac2 [snipped] This is a large scale merge of the pending queue. It has not been extensively tested and is mostly for review/comment and to help people to get patches in sync. It might well work too 8) And I have asked this question *BECAUSE* I have a problem with an appliance using RedHat 7.2, and with the Linux kernel supplied by RedCrack. That's what I asked in the first place, if you had a problem with distro kernels or were just wondering, and my answer was qualified accordingly. NOTE: None of my machines run redhat kernels, they all run various 2.4 (-pre and -ac) and 2.5 kernels. I test Linus and Marcelo's latest kernels AND send patches to problems I discover. I'm sure there are many others like me who do the same thing. This does NOT constitute adequate QA and certainly has nothing to do with which kernel to run on a PRODUCTION server! -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? msg22153/pgp0.pgp Description: PGP signature
Re: linux 2.4.20-pre?-ac? kernels
Ariel Biener wrote: On Thu, 26 Sep 2002, Muli Ben-Yehuda wrote: shape or form. Why don't you use the vendor's kernels? For production use, that's definitely the safest bet. That is completely untrue, and also missleading to the whole community reading this thread. It is a sad fact that for example, RedHat kernels have a zillion of badly tested or even not that patches, which Linus and the Linux kernel development team would never insert in the kernel just like that. Really? Where do you get your info from? RedHat kernels go through extensive QA tests. As for stability and benchmarks, take a look at this article from Moshe Bar: http://www.byte.com/documents/s=2470/byt1012259408690/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
RE: linux 2.4.20-pre?-ac? kernels
I wanna say that people need to base their claims on facts instead of flailing their arms in the air(less they would hit someone). In the past i only worked with Redhat Distributions (underline), which is quite different then just referring to a specific kernel version which may or may not have some obscure bug that ur junkyard composed computer, didn't ran on, and probably because u don't know how to compile a module!. Anyway, what do u mean performance? what are you running? a cluster? I rarely hit the 100% cpu thingy, and I don't have an internal clock that can count the few percentage of milliseconds improvements. Usually when I install Linux, I use redhat dist with the default kernel, unless I wanna do something radical and patching etc..(or something stupid :) I can tell u, there is no joy to need to go and reboot a computer a few miles from u, or pay someone to do it on another continent. better lower the chances that it'll happen by using a kernel that went thru QA. Another important thing, is responsibility. It is no secret that untested kernel/clean can wipe ur disk and mess inodes. My guess is that people who claim that clean kernels are better, did not install these kernels on an important production servers, because it would be irresponsible. sure, I use clean kernels for a few years as my personal router server because I like to play with network patches etc, but I can tell u that for friends or businesses I would never install it, even if they would insist because it would cost more to just return and fix it anytime there is a bug or if there was a serious bug that could wipe their hd and who do u think they would blame? they are not techies, so u can be fairly sure they would blame u! * - * - * Tzahi Fadida [EMAIL PROTECTED] Technion Email: [EMAIL PROTECTED] My Cool Site: HTTP://WWW.My2Nis.Com * - * - * - * - * - * - * - * - * - * WARNING TO SPAMMERS: see at http://members.lycos.co.uk/my2nis/spamwarning.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of voguemaster Sent: Thursday, September 26, 2002 1:44 PM To: Israeli Linux Mailing List Subject: Re: linux 2.4.20-pre?-ac? kernels I'm sorry to say, but you are wrong. Vendor kernels may not be the most optimized or feature-specific kernels because they're aimed at many users, but they are stable. Personally I have been using kernel 2.2.14-5 (the one that comes with RH 6.2) on my development system for over 3 years now (well, now I don't work at it quite as much but still..). Other experiences I have with RH kernels completely contradict what you have just said. Of course, these are only my own personal examples, but if you are to drop a bomb like this and shout that vendor kernels (RH specifically) are not stable, do back your claims up with facts. FACTS are examples for bugs and stability issues. I doubt you'll find more of those in vendor kernels of the major distributers than on pre-release kernels. Good day Eli 26/09/02 11:58:08, Ariel Biener [EMAIL PROTECTED] wrote: On Thu, 26 Sep 2002, Muli Ben-Yehuda wrote: shape or form. Why don't you use the vendor's kernels? For production use, that's definitely the safest bet. That is completely untrue, and also missleading to the whole community reading this thread. It is a sad fact that for example, RedHat kernels have a zillion of badly tested or even not that patches, which Linus and the Linux kernel development team would never insert in the kernel just like that. Not only that they are not *stable*, they are less stable than any pre kernel. There's so many different worlds So many different suns And we have just one world But we live in different ones.. - Dire Straits = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
dear people, i think there's some great confusion here about the usa of the term 'stable'. ariel (at least as far as i know) runs systems that bear a rather heavy load over network connections. most people run machines that do not bear that heavy load. thus, your definition of 'stable' is quite different. and its a rather known fact, that for realy heavy network, memory and processing load on linux, most of the 2.4 kernel series was rather flowed, at least until 2.4.18 came out. a company i worked with encountered lots of woes in this area (running a machine with redhat's kernel or any vanilla 2.4.X kernel, about 8-12 month ago) year back, perhaps 8 month back) in the lab and bombing it with traffic while running their application on it (which used a lot of memory), caused networking to stop working after several hours or half a day, in a repeatable manner. only when then eventually installed a variant of the 2.4 kernel with the 'aa' patches - did they manage to have a machine running steadily - and that certainly wasn't a tested kernel, back then, not to mention QA. you can argue that your experience was different as much as you will - but the fact was that the VM code caused problems on a machine that was hammered heavily the same problem existed with pre 2.4.10 kernels, that is 2.4.7, 2.4.9, etc). and as far as i know, not all of arcanageli's patches went into 2.4.19 (muli - please correct me if i'm wrong regarding this merge). this VM fiasco apparently did not have a parelel during the 2.2 kernel release cycle, or with earlier versions - it did happen with 2.4 . btw, at the same time, another company that used much earlier 2.4 kernels with an appliction that performs network processing - did not encounter _any_ problem. ofcoruse, they handled traffic flowing at only 10 mega-bit per second - and that did not use as much memory. and they were using very early 2.4 kernels (including some 2.4-test kernels) - and had no problems. so from their point of view, 2.4 was stable since quite long ago. so, i'd say again - stability depends on what you're doing with the system. and QA alone cannot fix problems stemming from major bugs in the underlying system. -- guy For world domination - press 1, or dial 0, and please hold, for the creator. -- nob o. dy = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
26/09/02 15:46:11, guy keren [EMAIL PROTECTED] wrote: dear people, i think there's some great confusion here about the usa of the term 'stable'. ariel (at least as far as i know) runs systems that bear a rather heavy load over network connections. most people run machines that do not bear that heavy load. thus, your definition of 'stable' is quite different. and its a rather known fact, that for realy heavy network, memory and processing load on linux, most of the 2.4 kernel series was rather flowed, at least until 2.4.18 came out. a company i worked with encountered lots of woes in this area (running a machine with redhat's kernel or any vanilla 2.4.X kernel, about 8-12 month ago) year back, perhaps 8 month back) in the lab and bombing it with traffic while running their application on it (which used a lot of memory), caused networking to stop working after several hours or half a day, in a repeatable manner. only when then eventually installed a variant of the 2.4 kernel with the 'aa' patches - did they manage to have a machine running steadily - and that certainly wasn't a tested kernel, back then, not to mention QA. you can argue that your experience was different as much as you will - but the fact was that the VM code caused problems on a machine that was hammered heavily the same problem existed with pre 2.4.10 kernels, that is 2.4.7, 2.4.9, etc). and as far as i know, not all of arcanageli's patches went into 2.4.19 (muli - please correct me if i'm wrong regarding this merge). this VM fiasco apparently did not have a parelel during the 2.2 kernel release cycle, or with earlier versions - it did happen with 2.4 . btw, at the same time, another company that used much earlier 2.4 kernels with an appliction that performs network processing - did not encounter _any_ problem. ofcoruse, they handled traffic flowing at only 10 mega-bit per second - and that did not use as much memory. and they were using very early 2.4 kernels (including some 2.4-test kernels) - and had no problems. so from their point of view, 2.4 was stable since quite long ago. so, i'd say again - stability depends on what you're doing with the system. and QA alone cannot fix problems stemming from major bugs in the underlying system. -- guy True, but then how would you explain the article by Moshe ? He tested several 2.4 kernels and the RH 7.2 kernel, while a bit slower, was stable. Eli There's so many different worlds So many different suns And we have just one world But we live in different ones.. - Dire Straits = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On Thu, 26 Sep 2002, voguemaster wrote: True, but then how would you explain the article by Moshe ? He tested several 2.4 kernels and the RH 7.2 kernel, while a bit slower, was stable. different usage patterns. btw, i didn't read the article. thought it does not matter - the fact that it worked for one test can NOT be used to refute the case that it did NOT work for another test. and by telling ariel you are talking bullshit because it works for us - you are not making a good case. fact is, that it didn't work. and as far as i know ariel, i don't think he would go saying something did not work without doing some proper testing, and without realy seeing it not testing. on the other hand, i don't think its redhat's fault at all - its the fault of the 2.4 kernel developers, and their decision making. the good thing, is that we can see a path of it stabilizing - but it took quite long to stabilize. now, here is a question for those 'in the know' - how far is alan cox involved in choosing what patches go into redhat's kernel version, since he begun working for them? or, who in redhat decides on that? -- guy For world domination - press 1, or dial 0, and please hold, for the creator. -- nob o. dy = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
voguemaster [EMAIL PROTECTED] writes: True, but then how would you explain the article by Moshe ? He tested several 2.4 kernels and the RH 7.2 kernel, while a bit slower, was stable. Lies, damn lies, statistics, and benchmarks... Please don't compare apples and oranges. Moshe's benchmarks do not include heavy network traffic, which was Guy's point. OTOH, I believe Guy's point was more relevant to 2.4 vs. 2.2. Vanilla 2.4 vs. RH 2.4 is different. So is pre??-ac?? vs. stable. -- Oleg Goldshmidt | [EMAIL PROTECTED] = ... Of theoretical physics and programming, programming embodied the greater intellectual challenge. [E.W.Dijkstra, 1930 - 2002.] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On Thu, Sep 26, 2002 at 05:40:33PM +0300, guy keren wrote: now, here is a question for those 'in the know' - how far is alan cox involved in choosing what patches go into redhat's kernel version, since he begun working for them? or, who in redhat decides on that? He has been on record in lkml stating that he is involved but does not have the final say (I could dig up the reference if required). Redhat's kernel maintainer is Arjan van de Ven. Why? -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? msg22161/pgp0.pgp Description: PGP signature
Re: linux 2.4.20-pre?-ac? kernels
On Thu, 26 Sep 2002, Nadav Har'El wrote: various versions of Redhat. I suspect that some of the people trashing Red- Hat are not actually using it, and are just assuming things. I think it's safe to say I wouldn't dare assuming things on a public mailing list. all that serious (reiserfs filesystemscould not be umounted). In fact, I found Redhat's kernels to be very stable. I guess you are not using them in the manner a large enterprise like TAU uses it. I guess you really love Red-Hat :) I actually run RedHat, and TAU is RedHat all across the board, from users workstations to Linux servers. I just don't like their kernel distribution trees that *come with the releases*. Yes, a few months later they release much stabler kernels for that said release, but this is not how it is supposed to be. Please don't learn manners from Linus :( Referring to people you don't agree with as drug addicts is not a very nice thing... Well, I would like to learn a great deal from Linus, but manners is not on my list. --Ariel -- Ariel Biener e-mail: [EMAIL PROTECTED] PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On 26 Sep 2002, Oleg Goldshmidt wrote: Hi, I'll make it to the point. It seems that from the reactions (except Guy) I got on this list, no one really understands the nature of what a production server means in terms of performance, while you do understand what it means in terms of accountability and risk taking. The system I was talking about handles mail for 50,000 users, using postfix on one system (mail spool and mailqueue are on a netapp connected with GigE to that system), and another system (exactly the same) that does imap/imaps/pop/pops. Both are capable of doing everything, and a service monitor using a DNS sub domain is handling failures of each service, moving the service to the other host. The system moves about 100,000 emails per day, peaks at 120-130k. There are a few hundred PCs at TAU in offices (I am excluding classes and other stuff) that are defined to check mail every 5 minutes, so every 5 minutes there is a huge burst of connections. The importance of NFS performance and stability over the GigE to the Netapp is of course crucial, and so is the VM, for handling the load, the many processes running, and proper handling of high speed networking. I was thinking of posting the idea behind the system and approximate costs to this list long ago, as it saved us alot of money, and I believe the design we use is both robust and scalable (to a point of course). For this system, RedHat distro kernels just didn't do, while 2.4.18-pre3-ac2 that runs there for a year or close to it works great. There are also other problems with xinetd's robustness and other issues that required tuning, including tcp stack tuning for ADSL users and other issues. I send very few messages to this list. We experienced with this for over a year till I sent this mail. I generally do not tend to shoot up unsubstantiated claims in the air and waste everyone's time. best, --Ariel -- Ariel Biener e-mail: [EMAIL PROTECTED] PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On Thu, Sep 26, 2002 at 06:18:58PM +0300, Ariel Biener wrote: [snipped] I send very few messages to this list. We experienced with this for over a year till I sent this mail. I generally do not tend to shoot up unsubstantiated claims in the air and waste everyone's time. Ariel, Thanks for that good explanation of what you need from a kernel. Had you sent it in the first place, I venture to guess you would have received far more constructive responses from the list, and certainly from me. Now, could you explain furtherm, if the setup is already working, why are you considering upgrading the kernel? Are there specific bottle necks that you're running into? You might also want to consider redhat's Advanced Server kernel, which has several patches that might (or might not) make a difference for your usage. It is geared for databases, but your servers probable usage patterns sound similar. -- Muli Ben-Yehuda http://www.mulix.org/ [EMAIL PROTECTED]:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/ Quis custodes ipsos custodiet? msg22164/pgp0.pgp Description: PGP signature
Re: linux 2.4.20-pre?-ac? kernels
On Thu, 26 Sep 2002, Muli Ben-Yehuda wrote: Now, could you explain furtherm, if the setup is already working, why are you considering upgrading the kernel? Are there specific bottle necks that you're running into? The overview I gave was to explain a pattern of behaviour we have with really stressed servers here. The service I experienced problem with is different, and since it's part of a non-disclosure agreement we have, I cannot specify more. What I can say it that it's a system running an application which has to be able to deal with ~100Mbit/s full duplex (50 in 50 out). The system also does ALOT of IO, the system is dual CPU, runs a database that works pretty hard, and runs 1GB of memory that are ~80% used. The problems started after upgrading to 1GB memory, I assume because the pattern of operation changed (less swapping). The problem occurs in kjournaled in a reproductivable manner, but I do not think kjournald is the problem, but that something else gets stuck, which causes kjournald to fail, and then the system stops. --Ariel -- Ariel Biener e-mail: [EMAIL PROTECTED] PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On Thu, 2002-09-26 at 18:43, Ariel Biener wrote: The overview I gave was to explain a pattern of behaviour we have with really stressed servers here. The service I experienced problem with is different, and since it's part of a non-disclosure agreement we have, I cannot specify more. What I can say it that it's a system running an application which has to be able to deal with ~100Mbit/s full duplex (50 in 50 out). The system also does ALOT of IO, the system is dual CPU, runs a database that works pretty hard, and runs 1GB of memory that are ~80% used. What device is used for networking? 100Mbit/s on most regular NICs and drivers will kill the system because of interrupt livelock. You *might* benefit alot from using the NAPI network drivers patches, if applicable, which will go to 'polling mode' instead of 'interrupt mode' over specific traffic loads to avoid overloading the system (but still continue to pump packets in and out). I have no idea if this has something to do with the situation your experiencing, but if you do see a really huge numbers of interrupts (/proc/interrupts) during high network loads this might be a good idea in any case and will decrease the load of the system. Gilad. -- Gilad Ben-Yossef [EMAIL PROTECTED] http://benyossef.com Geeks rock bands cool name #8192: RAID against the machine = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On 26 Sep 2002, Gilad Ben-Yossef wrote: What device is used for networking? 100Mbit/s on most regular NICs and drivers will kill the system because of interrupt livelock. You *might* benefit alot from using the NAPI I said 50Mbit/s in + 50Mbit/s out at peaks, 20Mbit/s in 20Mbit/s out average. I have no idea if this has something to do with the situation your experiencing, but if you do see a really huge numbers of interrupts (/proc/interrupts) during high network loads this might be a good idea in any case and will decrease the load of the system. Would this count as huge ? 17: 186608169 186641281 IO-APIC-level eth1 7:47pm up 1 day, 28 min, 5 users, load average: 0.23, 0.82, 1.25 If I count it right, this is: 186608169/86428 int/sec per cpu, that is 2159 int/second. --Ariel -- Ariel Biener e-mail: [EMAIL PROTECTED] PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Qtext
On Wed, 25 Sep 2002, Moshe Kaminsky wrote:
Guy Baruch [EMAIL PROTECTED] [25/09/02 12:27]:
There's something in this thread I may be a bit too simple to understand.
I assume bidi support is really better than in current products, are the
algorithms
patented?
This question never occured to me, and he didn't mention anything about
it. I think that when he released the first versions, people were not
patenting algorithms, and I don't think he ever published the algorithm,
so my guess is that they are not patented. I'll ask him. Anyway, he
claims (and I believe him) that bidi support in Qtext is significantly
better than in M$ word.
Word8 (that is: Word97), you mean.
if so, I'm not really sure what good will releasing _the source_ to public
domain will do, at least for law-abiding entities ( {persons} \subset
{entities} ... :) ).
If , OTOH, there are no patents, than wouldn't releasing the source be
beneficial to other projects regardless of the porting effort ?
Yes, assuming the people who work there are willing to read the source,
extract the algorithms and apply them to those projects (which, I guess,
might be quite a lot of work). If they *are* willing to do this, perhaps
getting the algorithms will be easier than getting the source.
libbidiqtext may be nice, but...
Currently fribidi, IBM's ICU and QT3 both implement basically the same
algorithm for converting logical-visual text. (as defined in the unicode
standard). This standard does not define how an interactive application
that edits text should behave, and leaves a number of problematic issues,
but I tend to suspect that qtext's algorithms deviate from it.
Qtext itself is the immediate destination. The ability to read and do
something useful with qtext files would also be nice.
--
Tzafrir Cohen
mailto:[EMAIL PROTECTED]
http://www.technion.ac.il/~tzafrir
=
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word unsubscribe in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
Re: BitKeeper Cont. [was Re: My projects are gone (fwd)]
Shlomi Fish wrote: Hi Oded! I love it that people decide the victim is the one responsible. I have not examined all the evidence, but even judging from just what you said my opinion is that you are in the wrong (and like any human, I'm sure you are at least just a tiny bit biased in your favor) - if not morally and ethicly, then at least in your attitude. snip Granted, the post to bitkeeper-users was off-topic, and may have been trollish. I did not know it was off-topic at the time. Hmm.. sounds familiar ;-) Furthermore, I believed I did Larry a favour by opening the bitkeeper-license mailing list. That may be, time would tell - but I don't consider opening a mailing list for discussions on the licensing policies of other people's software, w/o getting said persons' premission first, to be done in good faith, and I don't fault Larry for not taking to it gracefully. flame-bait and irrational Larry McVoy is. (if you want I can send you a very insulting letter he sent me). No thank you. You are talking about the life's work and mind creation of a person as its a commodity and property of the community in general, when its obvious that the author does not see it that way - I too would have been very sensitive and highly flamable on a subject like this. I am trying to free BK or outcompete it (preferably the first option). You are talking about taking control of another person's creation w/o that persons agreement (!!) most people would call that outright theft - I do not understand how can you not understand Larrry's reaction to that. And I now decided that I am pro BK not against it, Good for you. 3. Removing the data without my explicit permission is something I consider a malicious misplacement of information. The storage space was not yours in the first place - you have nothing to complain about. it would have been wrong to use your intelectual property w/o your premission, but as they only deleted it, I see nothing wrong here. it would be nice of them to give you a fair warning, but that's all. Wait a second - am I smelling a whiff of double standards here ? I don't agree with Larry McVoy's licensing policy or the use requirements he forces on BK users, which is the only reason why my company is not using BitKeeper today, but after all its his software to do with which he peleases - and that IMHO is the real cause behind the free software movement: that you are free to release your software under which license that you choose and be judge by its merits (and licensing policy) alone. You may use BitKeeper according to its terms of use, or you may choose not to, you may write your own SCM software suit or PR another, you may even talk harshly about Larry McVoys licensing policy. but you may not, ever, activly take steps to undermine a person's control or ownership of the software he or she has written. Once Larry McVoy said that he will not GPL BitKeeper, then thats it. end of discussion. -- Oded ::.. Every journalist has a novel in him, which is an excellent place for it. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: RH8 Mdk9
Hi Mark On Wed, 25 Sep 2002, Hetz Ben Hamo wrote: The statistics become much higher when you realize that: 1. Redhat wants to change the buggy 2.96 compiler (which actually has about 5 versions I am ware of that they refuse to admit or tag as different versions). Please get some facts straight regarding gcc 2.96: http://www.bero.org/gcc296.html I get no response from the serve, try google's cache: http://216.239.39.100/search?q=cache:14MxugUNW6gC:www.bero.org/gcc296.html+bero+gcc+2.96hl=enie=UTF-8 [snip] This is not an impartial person (Bero works for Redhat), but it will help you understand why redhat *needed* to fork gcc, and maybe why Mandrke decided that it was actually a good idea and followed it. -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On Thu, 2002-09-26 at 19:49, Ariel Biener wrote: Would this count as huge ? 17: 186608169 186641281 IO-APIC-level eth1 7:47pm up 1 day, 28 min, 5 users, load average: 0.23, 0.82, 1.25 If I count it right, this is: 186608169/86428 int/sec per cpu, that is 2159 int/second. I'm not familier with your setup and enviorment and I dont want to say things I'm not 100% sure about, but it does sound a lot to me. Your machine seems to have done more network interrupts in 1 day then a reasnoably loaded web server I have access to did in the last 50... Again, I *don't* know if this is the cause of your problems, but taking into account that the interrupt rate and thus the CPU resources it consumes will increase exactly when the system is loaded and need CPU time most for VM managment, swapping and of course - your application it *might* be something to consider. As mentioned already teh NAPI patches can provide a solution and under normal circumstances I would advice to try them out. I don't know how feasible this is on the specific machine you are using. Maybe you have a testing facility of some sort to avoid doing this on a production unit (always a good idea IMHO :-) One other thing you have to consider is that on SMP systems having both CPUs servicing the network card means you'll end up with a LOT of packet reordering. This can increase load further as the TCP/IP stack will have to put them in order whcih is quite a costly thing - on the Internet packet reordering is quite rare. The usuall solution is to put the NICs on CPU affinity - to tie their handling witgh a specific CPU. This can be done via the /proc interface, don't remember exactly where. This two may or may not help you. Cheers, Gilad. -- Gilad Ben-Yossef [EMAIL PROTECTED] http://benyossef.com Geeks rock bands cool name #8192: RAID against the machine = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here are my thoughts on the matter (as if anyone cares what they are...:): 1. No commercial company has EVER produced a portable kernel (a real portable kernel - no branches like solaris or windows on alpha). This is probably due to the patience one has to have by letting fixes in not-so-hot architectures break things (sometimes or even by accident) in architectures which are of importance. For instance - Linus will admit a change which will make architecture dealing more flexible because of requirement from the alpha team thereby forcing the i386 to flex development effort even though the 386 code doesnt need that fine granularity (it works fine without it). NO ADMINISTRATOR in a commercial company will EVER do that (meaning risk breaking the code on the most used platform because of an almost non existant number of users on a almost unknown platform). That is why commercial comapanies never develop portable kernels. Plus the long boot time for such a project (A company will rarely invest money in something it will only see returns on 10 years down the line - maybe). 2. Due to (1) we now conclude that commecial companies COULD HAVE NEVER produced a product similar to Linux in capability. The only products that are equivalent are the BSD kernels which are open source too. 3. Nor do commercial companies able to support it on their own (Just as a fact up till now no commercial company has forked Linux and tried to take it into one of their developers hands - you may claim that this is due to the fact that they think the followers will stay with Linus but when you think of it none of them will dare do that on a TECHNICAL level). 4. Since free source produces better operating systems than commercial companies why should we assume that open source does worse on QA ? I claim that open source does BETTER on QA. You don't see RH doing QA on a lot of other products (if you divide their staff by number of packages you will have to reach a situation where every QA guy is in charge of about 50 packages). They are not. Why ? open source is good enough. The most they do is packaging and sometimes security fixes. Most bugs work themselves out the usual free source way. The QA RH does is overall QA to make sure that the combinations of products they select do not interfere one with the other. If they do QA on a specific product then they 5. Then why has RH decided to specifically QA the kernel ? You may claim, rightly, that the kernel is the most important component. It is also a component which is always running and therefore each bug in the kernel is much more important than in some application. You would also be right. That is probably the reason. Plus the fact that RH has clients with hardware that is not currently supported in the kernel and they want the kernel to support it and therefore they add drivers which sometimes even demand deeper changes. Once you start doing that you risk breaking something REALY important and presto - you HAVE to have your own QA team to make sure you didn't do that. 6. The open source way of QA is totally different. Don't change anything of importance and fix bugs all the time (that is what is being done on the stable branch). I think that the stable branch is quite conservative in what is accepted there (I think much more outrageous patches are accepted by the distributions). The distributions can also have different kernel sources for different architectures (i386,sparc etc...) which open source doesn't do (the whole point is to have 1 source tree). 7. Now lets look at the numbers. Redhat released 2 kernels for my platform (RH7.2). 2.4.7 and 2.4.9. The first was a total disaster. The vanilla 2.4.7 worked much better (although, it too, had it's problems). In this case RH botched up. Even with QA. Not very good track record. 8. A simple system (which should have been in place long ago) where people vote on the stability of kernels or an automatic system where your kernel reports up time to some website (ONLY if you enable that explicitly ofcourse) could be built up. The statistics that we would get should show the best vanilla stable kernel with NO problem what so ever. The oops kernels would stand up like flag poles. This type of system will provide much better kernels than RH QA. All that a distribution would have to do is look at the last N stable kernels and pick the best one. Presto. 9. And here is the real issue: once RH dabbles inside the kernel they are not only making it more stable - they are also risking introducing subtle bugs. If RH QA doesnt find anything wrong with the vanilla kernels we can sack them all since what good are they ? the whole point of QA is to find bugs and fix them. If QA doesn't find any bugs there is no need for them. If RH QA is indeed working then it must find bugs. And if it doesn't fix them it is as useless as no QA. Then it must fix them.
Re: frequent ADSL disconnections
On 2002-01-25, Daniel Pearson wrote: [snip] As you may have guessed, I am able to successfully connect to and use the Internet via DSL. The problem is that the connection suddenly stops working at rather frequent, but very irregular intervals. When this happens packets don't go through at all, and pppd soon gives up on the connection and exits because it is no longer receiving responses to its LCP echo requests. Dear searcher of the list archives who may find this useful, I had a similar sporadic disconnections problem using a new Alcatel SpeedTouch Home modem. Replacing the network card, as suggested by Eli Marmor, solved it. The problematic NIC was a Tulip-based Kingston 10BaseT/10Base2 card (which *does* work with the Orckit ATUR3 modem when given the options=4 module argument). The good NIC is based on the Intel 82557 (eepro100). Regards, Eran = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On Thu, 26 Sep 2002, Mark Veltzer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here are my thoughts on the matter (as if anyone cares what they are...:): 1. No commercial company has EVER produced a portable kernel (a real portable kernel - no branches like solaris or windows on alpha). Didn't the late NT/alpha and NT/MIPS share the same codebase as NT/i386? What about the late BeOS (PowerPC and i386, IIRC)? 2. Due to (1) we now conclude that commecial companies COULD HAVE NEVER produced a product similar to Linux in capability. The only products that are equivalent are the BSD kernels which are open source too. 3. Nor do commercial companies able to support it on their own (Just as a fact up till now no commercial company has forked Linux and tried to take it into one of their developers hands - you may claim that this is due to the fact that they think the followers will stay with Linus but when you think of it none of them will dare do that on a TECHNICAL level). Linux is distributed under the terms of the GPL. Everyone is free to fork, but if the forked modifications are distributed, ten so must their sources be. If those changes will have something useful, it will find its way (e.g: through vendor kernels) to the main kernel tree. 4. Since free source produces better operating systems than commercial companies why should we assume that open source does worse on QA ? I claim that open source does BETTER on QA. You don't see RH doing QA on a lot of other products (if you divide their staff by number of packages you will have to reach a situation where every QA guy is in charge of about 50 packages). They are not. Why ? open source is good enough. The most they do is packaging and sometimes security fixes. Most bugs work themselves out the usual free source way. The QA RH does is overall QA to make sure that the combinations of products they select do not interfere one with the other. If they do QA on a specific product then they It is a bit difficult to show the QA work. So I'll give a simple example to one side-asspect of it. Below is a link to the archives of redhat's enigma-list, which is the list for public discussions of matters regarding redhat's before-latest beta. Public beta is not exactly internal QA (everything found there is something that was not found in QA) but still it saves many thing from paying costumers. 5. Then why has RH decided to specifically QA the kernel ? You may claim, rightly, that the kernel is the most important component. A kernel is just one of the important component, without which a linux distro can't function It is also a component which is always running and therefore each bug in the kernel is much more important than in some application. You would also be right. That is probably the reason. Plus the fact that RH has clients with hardware that is not currently supported in the kernel and they want the kernel to support it and therefore they add drivers which sometimes even demand deeper changes. Once you start doing that you risk breaking something REALY important and presto - you HAVE to have your own QA team to make sure you didn't do that. 6. The open source way of QA is totally different. Don't change anything of importance and fix bugs all the time (that is what is being done on the stable branch). I think that the stable branch is quite conservative in what is accepted there (I think much more outrageous patches are accepted by the distributions). The distributions can also have different kernel sources for different architectures (i386,sparc etc...) which open source doesn't do (the whole point is to have 1 source tree). 7. Now lets look at the numbers. Redhat released 2 kernels for my platform (RH7.2). 2.4.7 and 2.4.9. The first was a total disaster. The vanilla 2.4.7 worked much better (although, it too, had it's problems). In this case RH botched up. Even with QA. Not very good track record. 2.4.9 was labeled as a security fix. It also included some bug fixes, I figure. Recall that at the time of 2.4.x (for a small enough x) people were complaining about problems with vanilla kernels, and not about RH kernels. 8. A simple system (which should have been in place long ago) where people vote on the stability of kernels or an automatic system where your kernel reports up time to some website (ONLY if you enable that explicitly ofcourse) could be built up. The statistics that we would get should show the best vanilla stable kernel with NO problem what so ever. Please explain how would such a voting concider issues of different hardwares, and different usage patterns. The oops kernels would stand up like flag poles. What about those generated by hardware problems? This type of system will provide much better kernels than RH QA. All that a distribution would have to do is look at the last N stable kernels and pick the best one. Presto. But by the time you would have the results,
Re: linux 2.4.20-pre?-ac? kernels
On Thu, Sep 26, 2002, Ariel Biener wrote about Re: linux 2.4.20-pre?-ac? kernels: I'll make it to the point. It seems that from the reactions (except Guy) I got on this list, no one really understands the nature of what a production server means in terms of performance, while you do understand what it means in terms of accountability and risk taking. I am sorry, I didn't mean to imply that you didn't know what you were doing. I wasn't even replying directly to your post. It's just that over the last week, we've seen here a barrage of postings trashing Redhat. Everything from their choice of C compiler, choice of KDE/ Gnome customization, and now kernels. Some of the people saying those things (I never said all of them!) are not speaking from experience because they usually use a different distribution. All of them (including you, Ariel) were generalizing (I didn't realize you meant that Redhat's kernel was un-stable only on a specific sort of heavy-duty server with high VM load, I thought you were saying it was generally unstable). I just thought that this sort of defamation was unfair, and can bring a newbie reading this not to choose Redhat because I read on linux-il that its C compiler doesn't work, their desktop interface is broken and their kernel sucks. From my experience with Redhat and their packages, for everything from a development workstation to a gigabit-throughput web server, Redhat, while not without any fault, is a good, reliable system for most uses that most readers of this list will want. -- Nadav Har'El|Thursday, Sep 26 2002, 21 Tishri 5763 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |The path of least resistance is what http://nadav.harel.org.il |makes rivers and politicians crooked. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
[OT] Re: linux 2.4.20-pre?-ac? kernels
NB: marked OT with respect to the actual topic of the thread. Not entirely OT for the list, I suppose. Mark Veltzer [EMAIL PROTECTED] writes: .. and I will continue feeding trolls who contribute to the kernel ;-) 1. No commercial company has EVER produced a portable kernel I would give commercial companies the benefit of the assumption that whatever they produce or distribute is portable at least to all the officially supported platforms. Now, assume RH - the vendor in question - only support x86. They would be perfectly right in favoring things beneficial to x86 even when they are detrimental to other architectures. I see nothing wrong here. 2. Due to (1) we now conclude that commecial companies COULD HAVE NEVER produced a product similar to Linux in capability. I don't see how you arrived at this conclusion. I'd say just the opposite is true: a vendor that focuses on a particular architecture is likely to succeed in producing a *more capable* product for that platform. The only products that are equivalent are the BSD kernels which are open source too. I have little experience with BSD. Please enlighten me, what other architectures besides x86 are supported? 3. Nor do commercial companies able to support it on their own (Just as a fact up till now no commercial company has forked Linux and tried to take it into one of their developers hands - you may claim that this is due to the fact that they think the followers will stay with Linus but when you think of it none of them will dare do that on a TECHNICAL level). Well, apparently RH did ;-). Another example of a fork by a commercial company is BSD-related - OS X. Both are apparently successful. 4. Since free source produces better operating systems than commercial companies why should we assume that open source does worse on QA ? I don't understand why you are going down this road. RH are commercial *and* open source - which category do you put them in? I claim that open source does BETTER on QA. Better than RH? They are open source, and have probably the largest user base. I'd say it is natural to assume they do *at least* as well as non-commercial open source, because in addition to the common open source QA they also pay people to do extra QA for them. You don't see RH doing QA on a lot of other products (if you divide their staff by number of packages you will have to reach a situation where every QA guy is in charge of about 50 packages). This point is also flawed. It would make perfect sense to RH to specifically QA what they change. If they put an add-on package foo into the distro and do nothing to it but create an rpm, then they would probably QA the rpm, but not foo itself. I see bugs in various software I use. I don't blame RH for those bugs, and don't send them bug reports. I send reports to developers/maintainers of the software. Plus the fact that RH has clients with hardware that is not currently supported in the kernel and they want the kernel to support it and therefore they add drivers which sometimes even demand deeper changes. Once you start doing that you risk breaking something REALY important and presto - you HAVE to have your own QA team to make sure you didn't do that. True. What's wrong with that? 7. Now lets look at the numbers. Redhat released 2 kernels for my platform (RH7.2). 2.4.7 and 2.4.9. The first was a total disaster. The vanilla 2.4.7 worked much better (although, it too, had it's problems). In this case RH botched up. Even with QA. Not very good track record. Did vanilla 2.4.7 or 2.4.9 work much better for you? Unless the answer is yes, you cannot claim that it was RH who botched the job, can you? IIRC RH 7.2 never went beyond 2.4.9 because they did not quite trust the new VM at the time. Along the way they avoided the disastrous 2.4.15 (by your argument, you would assume it was better than anything RH were likely to produce and would install it), and shipped 7.3 with 2.4.18 which, by all accounts, is better than any of the previous 2.4 series. 8. A simple system (which should have been in place long ago) where people vote on the stability of kernels or an automatic system where your kernel reports up time to some website (ONLY if you enable that explicitly ofcourse) could be built up. The statistics that we would get should show the best vanilla stable kernel with NO problem what so ever. The oops kernels would stand up like flag poles. This type of system will provide much better kernels than RH QA. All that a distribution would have to do is look at the last N stable kernels and pick the best one. Presto. Easier said than done. You will have to set up this experiment very carefully and in a controlled environment, with no forced reboots, scheduled or otherwise, same rate of power failures, similar loads of various types. Otherwise, your statistics will be meaningless. 9. If they fix them it means that they know HOW to fix them!!!
Re: linux 2.4.20-pre?-ac? kernels
On Thu, Sep 26, 2002, Mark Veltzer wrote about Re: linux 2.4.20-pre?-ac? kernels: 10. What (9) means is that RH kernels will be more stable than vanilla kernels only if: a. RH don't do a lot of changes. b. the changes are not of great depth. c. the fixes are obvious. d. most of the fixes are for drivers. If this is the case then indeed RH kernels could be better than vanilla. But what these conditions actually mean is that RH is NOT FAR from vanilla. This probably means that the vanilla version is pretty good as well!!! Funny how life is... There's one issue you forgot: there have been dozens and dozens of vanilla kernel releases in the 2.4 series (for example). 2.4.0 through 2.4.19, various sorts of -aa, -ac, and other sorts of big patches meant to solve various problems in those various official versions. If you read the linux- kernel mailing list (watch out, hundreds of posts per day) you'll see all those various versions being announced, and some of them later denounced. Now, which is better, taking some Redhat kernel that came, say, with Redhat 7.2 (or one of its updates), or randomly selecting the latest kernel at that time, say 2.4.13? Well, the truth is that many of the 2.4.* early kerels were duds, with serious problems (e.g., filesystem corruption, serious VM issues under high load, etc.); Redhat had to choose the more stable of the bunch to ship to their customers. Even if they didn't include any extra fixes in their kernels, the mere fact that they tried to make sure that they are shipping the more-stable kernels of the series was important. At least for people that don't have the resources to check a dozen kernels to see which one fairs best on a very specific type of high load - in other words, most of the members of this list. Anyway, as Ariel later explained, he *is* trying to see which kernel fairs best for a specific workload - in which case he is probably right, Redhat's checking and patching might not be at all relevant to his needs, because he might be able to do it better for his very specific needs. -- Nadav Har'El|Thursday, Sep 26 2002, 21 Tishri 5763 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |From the Linux getopt(3) manpage: BUGS: http://nadav.harel.org.il |This manpage is confusing. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 26 September 2002 21:50, you wrote: On Thu, 26 Sep 2002, Mark Veltzer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here are my thoughts on the matter (as if anyone cares what they are...:): 1. No commercial company has EVER produced a portable kernel (a real portable kernel - no branches like solaris or windows on alpha). Didn't the late NT/alpha and NT/MIPS share the same codebase as NT/i386? No they didn't. The alpha got forked off quite early. That's why MS dumped the alpha road (it was getting a burden to fix bugs for a minority of users). What about the late BeOS (PowerPC and i386, IIRC)? This one I don't know. My bet: Different source trees. 2. Due to (1) we now conclude that commecial companies COULD HAVE NEVER produced a product similar to Linux in capability. The only products that are equivalent are the BSD kernels which are open source too. 3. Nor do commercial companies able to support it on their own (Just as a fact up till now no commercial company has forked Linux and tried to take it into one of their developers hands - you may claim that this is due to the fact that they think the followers will stay with Linus but when you think of it none of them will dare do that on a TECHNICAL level). Linux is distributed under the terms of the GPL. Everyone is free to fork, but if the forked modifications are distributed, ten so must their sources be. If those changes will have something useful, it will find its way (e.g: through vendor kernels) to the main kernel tree My point was that they DONT fork. Why are they NOT forking when they can ? This is in effect an admittion that open source hackers can do better than they are. . 4. Since free source produces better operating systems than commercial companies why should we assume that open source does worse on QA ? I claim that open source does BETTER on QA. You don't see RH doing QA on a lot of other products (if you divide their staff by number of packages you will have to reach a situation where every QA guy is in charge of about 50 packages). They are not. Why ? open source is good enough. The most they do is packaging and sometimes security fixes. Most bugs work themselves out the usual free source way. The QA RH does is overall QA to make sure that the combinations of products they select do not interfere one with the other. If they do QA on a specific product then they It is a bit difficult to show the QA work. So I'll give a simple example to one side-asspect of it. Below is a link to the archives of redhat's enigma-list, which is the list for public discussions of matters regarding redhat's before-latest beta. Public beta is not exactly internal QA (everything found there is something that was not found in QA) but still it saves many thing from paying costumers. I agree. But as you can see most are integration bugs which is what RH does. Integration. 5. Then why has RH decided to specifically QA the kernel ? You may claim, rightly, that the kernel is the most important component. A kernel is just one of the important component, without which a linux distro can't function I agree. But it does not change my conclusions validity. It is also a component which is always running and therefore each bug in the kernel is much more important than in some application. You would also be right. That is probably the reason. Plus the fact that RH has clients with hardware that is not currently supported in the kernel and they want the kernel to support it and therefore they add drivers which sometimes even demand deeper changes. Once you start doing that you risk breaking something REALY important and presto - you HAVE to have your own QA team to make sure you didn't do that. 6. The open source way of QA is totally different. Don't change anything of importance and fix bugs all the time (that is what is being done on the stable branch). I think that the stable branch is quite conservative in what is accepted there (I think much more outrageous patches are accepted by the distributions). The distributions can also have different kernel sources for different architectures (i386,sparc etc...) which open source doesn't do (the whole point is to have 1 source tree). 7. Now lets look at the numbers. Redhat released 2 kernels for my platform (RH7.2). 2.4.7 and 2.4.9. The first was a total disaster. The vanilla 2.4.7 worked much better (although, it too, had it's problems). In this case RH botched up. Even with QA. Not very good track record. 2.4.9 was labeled as a security fix. It also included some bug fixes, I figure. Recall that at the time of 2.4.x (for a small enough x) people were complaining about problems with vanilla kernels, and not about RH kernels. 2.4.9 was a performance fix. I don't care what it was labeled. It prevented my machine from swapping
Re: [OT] Re: linux 2.4.20-pre?-ac? kernels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 26 September 2002 22:17, you wrote: NB: marked OT with respect to the actual topic of the thread. Not entirely OT for the list, I suppose. Mark Veltzer [EMAIL PROTECTED] writes: ... and I will continue feeding trolls who contribute to the kernel ;-) I think you have a very problematic undestanding of what a troll is. I was stating my opinions. If you think 1. No commercial company has EVER produced a portable kernel I would give commercial companies the benefit of the assumption that whatever they produce or distribute is portable at least to all the officially supported platforms. Now, assume RH - the vendor in question - only support x86. They would be perfectly right in favoring things beneficial to x86 even when they are detrimental to other architectures. I see nothing wrong here. 2. Due to (1) we now conclude that commecial companies COULD HAVE NEVER produced a product similar to Linux in capability. I don't see how you arrived at this conclusion. I'd say just the opposite is true: a vendor that focuses on a particular architecture is likely to succeed in producing a *more capable* product for that platform. Wrong. That is probably why MS windows is better on i386 than Linux right ?!? Every evidence shows that open source systems which are portable can certainly compete with the native operating system and sometimes out do them. This will much lower source size and much better in code architecture. The only products that are equivalent are the BSD kernels which are open source too. I have little experience with BSD. Please enlighten me, what other architectures besides x86 are supported? You are kidding me right ? Most BSDs are MORE portable than Linux. These NetBSD supports 39 architectures (and this is architectures supported INSIDE their source tree - I don't know how many more are supported outside). 3. Nor do commercial companies able to support it on their own (Just as a fact up till now no commercial company has forked Linux and tried to take it into one of their developers hands - you may claim that this is due to the fact that they think the followers will stay with Linus but when you think of it none of them will dare do that on a TECHNICAL level). Well, apparently RH did ;-). Another example of a fork by a commercial company is BSD-related - OS X. Both are apparently successful. Redhat didn't fork. They applied patches. Note the difference. So did Apple. They did not continue development of their tree (Are YOU trolling ?!?). 4. Since free source produces better operating systems than commercial companies why should we assume that open source does worse on QA ? I don't understand why you are going down this road. RH are commercial *and* open source - which category do you put them in? You obviously haven't been in the open source scene for long. In these types of discussions WITHIN the Linux community commercial means a distribution which makes money off of Linux compared to the community which doesnt make moeny. Open source here denotes the community. I claim that open source does BETTER on QA. Better than RH? They are open source, and have probably the largest user base. I'd say it is natural to assume they do *at least* as well as non-commercial open source, because in addition to the common open source QA they also pay people to do extra QA for them. Again, see comment above. You don't see RH doing QA on a lot of other products (if you divide their staff by number of packages you will have to reach a situation where every QA guy is in charge of about 50 packages). This point is also flawed. It would make perfect sense to RH to specifically QA what they change. If they put an add-on package foo into the distro and do nothing to it but create an rpm, then they would probably QA the rpm, but not foo itself. I see bugs in various software I use. I don't blame RH for those bugs, and don't send them bug reports. I send reports to developers/maintainers of the software. You say exactly what I did but claim by point is flawed. Are you trolling again ? Plus the fact that RH has clients with hardware that is not currently supported in the kernel and they want the kernel to support it and therefore they add drivers which sometimes even demand deeper changes. Once you start doing that you risk breaking something REALY important and presto - you HAVE to have your own QA team to make sure you didn't do that. True. What's wrong with that? Nothing. Just stating a fact. 7. Now lets look at the numbers. Redhat released 2 kernels for my platform (RH7.2). 2.4.7 and 2.4.9. The first was a total disaster. The vanilla 2.4.7 worked much better (although, it too, had it's problems). In this case RH botched up. Even with QA. Not very good track record. Did vanilla 2.4.7 or 2.4.9 work much better for you? Unless the answer is
Re: [OT] Re: linux 2.4.20-pre?-ac? kernels
On 26 Sep 2002, Oleg Goldshmidt wrote: I have little experience with BSD. Please enlighten me, what other architectures besides x86 are supported? NetBSD is probably the most portable OS (when considering a complete OS, not just a kernel). Although debian may nt be so far behind... -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: linux 2.4.20-pre?-ac? kernels
On Thursday 26 September 2002 16:46, guy keren wrote: dear people, i think there's some great confusion here about the usa of the term 'stable'. ariel (at least as far as i know) runs systems that bear a rather heavy load over network connections. most people run machines that do not bear that heavy load. thus, your definition of 'stable' is quite different. Up until few weeks ago - *.redhat.com ftp/web/mail servers were running RH's 2.4.18-10 kernel if I recall correctly.. Hetz To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: BitKeeper Cont. [was Re: My projects are gone (fwd)]
On Thu, 26 Sep 2002, Oded Arbel wrote: You are talking about taking control of another person's creation w/o that persons agreement (!!) most people would call that outright theft - Ayn Rand, too. --- Omer the null contributor to the Raanana InstParty WARNING TO SPAMMERS: see at http://www.zak.co.il/spamwarning.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Mandrake Linux Dolphin 9.0 is released, and ready to download!
Starting to download from... now ;) Enjoy, Adir. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Fwd: Re: Fwd: Re: linux 2.4.20-pre?-ac? kernels
Here's alan answer... Hetz -- Forwarded Message -- Subject: Re: Fwd: Re: linux 2.4.20-pre?-ac? kernels Date: Friday 27 September 2002 01:02 From: Alan Cox [EMAIL PROTECTED] From: Ariel Biener [EMAIL PROTECTED] TINC The importance of NFS performance and stability over the GigE to the Netapp is of course crucial, and so is the VM, for handling the load, the many processes running, and proper handling of high speed networking. The -ac2 and Red Hat VM are basically identical to answer that bit, both have the O(1) scheduler and both have similar but not identical NFS code. The 2.4.20pre has some better NFS code but still with glitches we are hunting down so thats not ideal There are also other problems with xinetd's robustness and other issues that required tuning, including tcp stack tuning for ADSL users and other issues. I'd be interested in more info on these - either to the list or to me directly. the list is redhat testers list - hetz To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
