[Haifux] SVN quota
Hello I have a LINUX server (RHE 4) that among other things serves as SVN server (the SVN server runs over apache). Users can access their repository via https, but they can't login to the server (not even with ssh). To access the SVN, users must supply their NIS user name & password. Every SVN repository has it's own quota limitation. The question is: do SVN users have any way to test their quota? (I don't want to write a cron job that warns the users when they are over 80% of the quota) Thanks Shahar___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
[Haifux] [HAIFUX LECTURE] The FOSS Community as a Social Phenomenon - Yaron Dishon
On Monday, January 18th (TODAY) at 18:30, Haifux will gather to hear Yaron Dishon (Haifa University, Sociology student) talk about a seminar work he recently did regarding The FOSS Community as a Social Phenomenon Hebrew Abstract: http://haifux.org/lectures/227/Abstract.pdf = We meet in Taub (CS Faculty) building, room 6. For instructions see: http://www.haifux.org/where.html Attendance is free, and you are all invited! Future Haifux events include: 1/02/10 Hspell: Nadav Har'El 15/02/10 VoIP in Linux: Rami Rosen We are always interested in hearing your talks and ideas. If you wish to give a talk, hold a discussion, or just plan some event haifux might be interested in, please contact us at webmas...@haifux.org ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Kernel oops, so what?
Thanks, Oron. You didn't just join in, but finally gave the full answer I was looking for. I tried to get a simple explanation on what these macros actually stand for, and couldn't find a single place where they were explained as simply as you put it. Eli Oron Peled wrote: OK, I'll join in... On Friday, 15 בJanuary 2010 16:27:34 Eli Billauer wrote: Now I get an oops warning every now and then, but nothing really happens. And I wonder what is going on? Has the dreaded oops become something one can live with? Nothing really changed that much. An Oops is caused by illegal operation in kernel space (e.g: null pointer dereference, division by zero etc.) It always had two possible results: 1. If it happened from an interrupt context -- a panic (prints a backtrace on the console and freeze the machine). 2. If it happened from a process context (e.g: in a system call), than it's a "normal" Oops -- Don't PANIC ;-) - The calling process is killed with a segfault (as we cannot continue any valid computation). - A normal context switch happens. - Everything continue normally, with the *hope* that there the bug did not cause big collateral damage (e.g: memory corruption) outside of the failed computation. For many years, there were several kernel macros for triggering such events from the kernel programmer side: - BUG() - causes an immediate panic - BUG_ON(condition) - think of it as a kernel "assert()" - WARN() - just the trace, no other ill effects - WARN_ON() - you guessed it. [for an un-favorite example, try to create a work-queue with a name longer than ~10 characters -- you'll get an immediate panic, you can see the code somewhere in kernel/workqueue.c] And then there's this site which collects oops reports (http://www.kerneloops.org/) which, judging by its sluggish response, is a pretty busy project. Oopses keep flooding in. 1. That's an important project that gives a "heads-up" call for code regressions. 2. Fedora-12 now installs it by default, and integrates it into a new bug-reporting framework (ABRT, a very buggy software in itself ;-) This enables sampling new kernels on a huge amount of configurations and scenarios that was not possible before. So, should I just take it cool and wait for a new kernel with this fixed, ignoring these messages? Yes, unless you joined the "kernel digging" hobby. However, this collaborative "bug-collection" frameworks increase the chance for a quicker fix. Cheers, -- Web: http://www.billauer.co.il ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Kernel oops, so what?
Tzafrir Cohen wrote: (there are two hpet.c in the kernel tree, but I won't be fussy) Two arch/x86/kernel/hpet.c? (the path from the message) Of course not. How would that be possible? And still, two files with the same name in the same project. I didn't know the police allowed that. Eli ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Kernel oops, so what?
OK, I'll join in... On Friday, 15 בJanuary 2010 16:27:34 Eli Billauer wrote: > Now I get an oops warning every now and then, but nothing really > happens. And I wonder what is going on? Has the dreaded oops become > something one can live with? Nothing really changed that much. An Oops is caused by illegal operation in kernel space (e.g: null pointer dereference, division by zero etc.) It always had two possible results: 1. If it happened from an interrupt context -- a panic (prints a backtrace on the console and freeze the machine). 2. If it happened from a process context (e.g: in a system call), than it's a "normal" Oops -- Don't PANIC ;-) - The calling process is killed with a segfault (as we cannot continue any valid computation). - A normal context switch happens. - Everything continue normally, with the *hope* that there the bug did not cause big collateral damage (e.g: memory corruption) outside of the failed computation. For many years, there were several kernel macros for triggering such events from the kernel programmer side: - BUG() - causes an immediate panic - BUG_ON(condition) - think of it as a kernel "assert()" - WARN() - just the trace, no other ill effects - WARN_ON() - you guessed it. [for an un-favorite example, try to create a work-queue with a name longer than ~10 characters -- you'll get an immediate panic, you can see the code somewhere in kernel/workqueue.c] > And then there's this site which collects > oops reports (http://www.kerneloops.org/) which, judging by its sluggish > response, is a pretty busy project. Oopses keep flooding in. 1. That's an important project that gives a "heads-up" call for code regressions. 2. Fedora-12 now installs it by default, and integrates it into a new bug-reporting framework (ABRT, a very buggy software in itself ;-) This enables sampling new kernels on a huge amount of configurations and scenarios that was not possible before. > So, should I just take it cool and wait for a new kernel with this > fixed, ignoring these messages? Yes, unless you joined the "kernel digging" hobby. However, this collaborative "bug-collection" frameworks increase the chance for a quicker fix. Cheers, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron __ / / (_)__ __ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a //_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . . ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
