Re: [Job Offer and a byte more] PHP programmer and CTO
Geoffrey S. Mendelson wrote: Shortly afterward they hired a new CFO and then a new CEO. Where did you get those facts? The company's web site still lists Gil Schwed as the CEO and Eyal Desheh as their CFO, both were at that position when I worked there, five years ago. Shachar = 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]
[Haifux Lecture] User space syscall tracing and manipulation - fakeroot-ng by Shachar Shemesh
Next Monday, 21th of Janaury, at 18:30 the Haifa Linux Club, will gather to Shachar Shemesh's lecture about User space syscall tracing and manipulation - fakeroot-ng Abstract Various techniques will be shown for wrapping another program's system calls. All techniques employ user-space only technology. This will range from the trivial (LD_PRELOAD) to the sophisticated (PTRACE+trampoline code). We will also discuss the various advantages and disadvantages of each technique. == We meet in Taub building, room 6. For location information see: http://www.haifux.org/where.html Attendance is free, and you are all invited! == Future Lectures: Crawling in Lightning Everybody! 11/2/2008 Tapping into the Fountain of CPUs---On Operating System Support for Programmable DevicesMuli Ben-Yehuda 25/2/2008 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 [EMAIL PROTECTED] -- Orr Dunkelman, [EMAIL PROTECTED] "Any human thing supposed to be complete, must for that reason infallibly be faulty" -- Herman Melville, Moby Dick. GPG fingerprint: C2D5 C6D6 9A24 9A95 C5B3 2023 6CAB 4A7C B73F D0AA (This key will never sign Emails, only other PGP keys. The key corresponds to [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: [Job Offer and a byte more] PHP programmer and CTO
On Thu, Jan 17, 2008 at 09:58:51AM +0200, Shachar Shemesh wrote: > Geoffrey S. Mendelson wrote: > > > > >Shortly afterward they hired a new CFO and > >then a new CEO. > > > Where did you get those facts? The company's web site still lists Gil > Schwed as the CEO and Eyal Desheh as their CFO, both were at that > position when I worked there, five years ago. Look at the chart I posted and move your mouse over the red K's. http://moneycentral.msn.com/investor/charts/chartdl.aspx?symbol=CKP Geoff. -- Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM IL Voice: (07)-7424-1667 U.S. Voice: 1-215-821-1838 Visit my 'blog at http://geoffstechno.livejournal.com/ = 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]
oops.
I want to appologize about my comments about Checkpoint. I looked at a stock page for Checkpoint Systems, inc, which is NOT!!! Checkpoint Software Technologies, the actual company in question. Their officers have not changed, the CEO and CFO are as the were, and what is on the website. The correct chart is at: http://moneycentral.msn.com/investor/charts/chartdl.aspx?symbol=CHKP If you look at the chart the CFO has announced he will leave and take a job at TEVA. The announcement was made in October, with an exit date of "mid 2008". The stock performance is not much different, a year ago it was $23.57 a share, it peaked in October at $25.98 BEFORE they announced a big contract and the departure of the CFO and it closed yesterday at $21.76. So it is not doing better than it did a year ago, and is significantly less than its peak. Draw whatever conclusions you wish. Geoff. -- Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM IL Voice: (07)-7424-1667 U.S. Voice: 1-215-821-1838 Visit my 'blog at http://geoffstechno.livejournal.com/ = 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]
Second opinion: oom-killer
Hi list, I need the esteemed people's second opinion to a recommendation I gave a client. The setup: Machine with 16GB ram and a bit of swap, running 32bit gentoo with (as far as I know) 3:1 memory split. The symptoms: Every so often the oom-killer kicks in, for no apparent reason. The processes it kills appear to be randomly chosen. Monitoring was not turned on, but there is no reason to suspect the 16GB+swap were nowhere near exhausted at the time. My suggested diagnosis and recommendations: The kernel only has 1GB with which to work, which causes it to run out of memory for managing the page tables. I recommended they: - As a first stage, disable the swap. - As a second stage - switch to a 64bit kernel My question is whether my diagnosis makes any sense, and if not, whether anyone has any better idea as to what might be the problem. Also, is there any way to monitor how much kernel memory is in use? It seems that monitoring the "LowTotal" and "LowFree" values in /proc/meminfo may be what I'm looking for, but I'm not sure I'm reading the docs proprely. Shachar = 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: Second opinion: oom-killer
On Thu, 2008-01-17 at 12:32 +0200, Shachar Shemesh wrote: > Hi list, > > > I need the esteemed people's second opinion to a recommendation I gave a > client. > > > The setup: > > Machine with 16GB ram and a bit of swap, running 32bit gentoo with (as > far as I know) 3:1 memory split. > > > The symptoms: > > Every so often the oom-killer kicks in, for no apparent reason. The > processes it kills appear to be randomly chosen. Monitoring was not > turned on, but there is no reason to suspect the 16GB+swap were nowhere > near exhausted at the time. > > > My suggested diagnosis and recommendations: > > The kernel only has 1GB with which to work, which causes it to run out > of memory for managing the page tables. I recommended they: > > - As a first stage, disable the swap. > > - As a second stage - switch to a 64bit kernel > > > My question is whether my diagnosis makes any sense, and if not, whether > anyone has any better idea as to what might be the problem. > > > Also, is there any way to monitor how much kernel memory is in use? It > seems that monitoring the "LowTotal" and "LowFree" values in > /proc/meminfo may be what I'm looking for, but I'm not sure I'm reading > the docs proprely. > > > Shachar If they can't use 64bit (for some reason), the 4G/4G split patch might solve the problem. (though you may need to dig out some ancient kernel to use it) - Gilboa = 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: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh
arbel yossi wrote: Hi, It is not clear from this post whether the lecture will deal with fakeroot-ng or not. The Abstract talks about various techniques but does not mention fakeroot-ng, while the title includes both. Regards, Yossi Fakeroot-ng is a (as far as I know) first attempt to do the things usually done with LD_PRELOAD using the ptrace mechanism. It was both the trigger and the root cause of this lecture. The lecture will look at fakeroot, fakechroot, fakeroot-ng and strace, at varying degrees of depths, mostly because all four chose slightly different approaches for solving, fundamentally, the same problem. Shachar = 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: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh
On Thu, Jan 17, 2008 at 12:45:10PM +0200, Shachar Shemesh wrote: > Fakeroot-ng is a (as far as I know) first attempt to do the things > usually done with LD_PRELOAD using the ptrace mechanism. It was both > the trigger and the root cause of this lecture. Not sure what you mean by "things usually done with LD_PRELOAD?" Certainly ptrace has been used to both trace and modify running binaries, by gdb, strace, dumpmem[1], memfetch[2] and others. I think I even gave a haifux talk on run-time modification of programs using ptrace for fun an profit a few years ago. > The lecture will look at fakeroot, fakechroot, fakeroot-ng and > strace, at varying degrees of depths, mostly because all four chose > slightly different approaches for solving, fundamentally, the same > problem. They did? Sounds like an interesting talk, will try to attend. [1] http://www.mulix.org/dumpmem.html [2] http://lcamtuf.coredump.cx/soft/memfetch.tgz Cheers, Muli = 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: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh
>Certainly ptrace has been used to both trace and modify running >binaries, by gdb, strace, dumpmem[1], memfetch[2] and others. You forgot system call tracker hijacking. DS On Jan 17, 2008 1:08 PM, Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote: > On Thu, Jan 17, 2008 at 12:45:10PM +0200, Shachar Shemesh wrote: > > > Fakeroot-ng is a (as far as I know) first attempt to do the things > > usually done with LD_PRELOAD using the ptrace mechanism. It was both > > the trigger and the root cause of this lecture. > > Not sure what you mean by "things usually done with LD_PRELOAD?" > Certainly ptrace has been used to both trace and modify running > binaries, by gdb, strace, dumpmem[1], memfetch[2] and others. I think > I even gave a haifux talk on run-time modification of programs using > ptrace for fun an profit a few years ago. > > > The lecture will look at fakeroot, fakechroot, fakeroot-ng and > > strace, at varying degrees of depths, mostly because all four chose > > slightly different approaches for solving, fundamentally, the same > > problem. > > They did? > > Sounds like an interesting talk, will try to attend. > > [1] http://www.mulix.org/dumpmem.html > [2] http://lcamtuf.coredump.cx/soft/memfetch.tgz > > Cheers, > Muli > > ___ > Haifux mailing list > [EMAIL PROTECTED] > http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux > = 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: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh
Dan Shimshoni wrote: Certainly ptrace has been used to both trace and modify running binaries, by gdb, strace, dumpmem[1], memfetch[2] and others. Yes, I am aware of all of the above except memfetch (I did not remember the names of dumpmem, but I did attend your lecture at the time). fakeroot-ng does take it a step further. I'll just point out a couple or three things (those that are either already implemented or will be implemented by the lecture): 1. Automatic manipulation. Unlike strace, fakeroot-ng actually changes the program while running. Unlike gdb, it does so automatically. 2. Syscall generation - program calls one syscall, you make it call three. 3. Recursive debuggers support - run strace (or fakeroot-ng, but at least at the moment not gdb) from within the fakeroot environment. You forgot system call tracker hijacking. syscall-tracker is not a user-space solution. DS Shachar = 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: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh
On Thu, Jan 17, 2008 at 02:12:31PM +0200, Shachar Shemesh wrote: > 1. Automatic manipulation. Unlike strace, fakeroot-ng actually >changes the program while running. Unlike gdb, it does so >automatically. When I did this in the past, it was always intimately tied to what the victim was doing. I'll be very interested in hearing how you got around it. > 2. Syscall generation - program calls one syscall, you make it call >three. Interesting... I assume this is without kernel support (e.g., UML's SKAs patches). > 3. Recursive debuggers support - run strace (or fakeroot-ng, but at > least at the moment not gdb) from within the fakeroot environment. Fun. Looking forward to the talk. Cheres, Muli = 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: Second opinion: oom-killer
I have no direct answer to your question. Oom-killer should be triggered in a memory emergency, and not when there's enough free memory space. Some notes though: A. oom killer doesn't randomly choose a process to kill.. I described the algorithm for choosing a candidate for killing in: http://www.held.org.il/blog/?p=18 (I *might* have missed something there, don't trust it 100%). B. I can't see why disabling the swap would help to AVOID oomkiller? Swap should ENLARGE the available memory space; disabling swap might cause triggering oomkiller more frequently. Maybe I misunderstood what you meant. - Oren On Thursday 17 January 2008 12:32, Shachar Shemesh wrote: > Hi list, > > > I need the esteemed people's second opinion to a recommendation I gave a > client. > > > The setup: > > Machine with 16GB ram and a bit of swap, running 32bit gentoo with (as > far as I know) 3:1 memory split. > > > The symptoms: > > Every so often the oom-killer kicks in, for no apparent reason. The > processes it kills appear to be randomly chosen. Monitoring was not > turned on, but there is no reason to suspect the 16GB+swap were nowhere > near exhausted at the time. > > > My suggested diagnosis and recommendations: > > The kernel only has 1GB with which to work, which causes it to run out > of memory for managing the page tables. I recommended they: > > - As a first stage, disable the swap. > > - As a second stage - switch to a 64bit kernel > > > My question is whether my diagnosis makes any sense, and if not, whether > anyone has any better idea as to what might be the problem. > > > Also, is there any way to monitor how much kernel memory is in use? It > seems that monitoring the "LowTotal" and "LowFree" values in > /proc/meminfo may be what I'm looking for, but I'm not sure I'm reading > the docs proprely. > > > Shachar > > > = > 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: Second opinion: oom-killer
Gilad Ben-Yossef wrote: - As a first stage, disable the swap. This doesn't make much sense to me. What is it suppose to achieve? It is SUPPOSED to achieve less memory to keep track of. As far as I understand it, the kernel keeps track over which virtual pages reside in which physical location, and therefor swap pages are being tracked not all that differently than physical memory. I might as well have told them to reduce the amount of physical memory to 8GB to achieve the same goal. And, yes, 8GB would probably be enough for the server to do what it's supposed to do. Of course, I could be wrong. That's why I'm asking here :-) Basically, you need enough free space in LowFree, for some definition of "enough". That's what I thought. Too bad Munin doesn't track that particular value, nor does top display it. In fact, for a value that has potential to cause so much grief, it is being practically ignored by standard monitoring tools. Gilad Shachar = 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: Second opinion: oom-killer
Shachar Shemesh wrote: Machine with 16GB ram and a bit of swap, running 32bit gentoo with (as far as I know) 3:1 memory split. The symptoms: Every so often the oom-killer kicks in, for no apparent reason. The processes it kills appear to be randomly chosen. Monitoring was not turned on, but there is no reason to suspect the 16GB+swap were nowhere near exhausted at the time. My suggested diagnosis and recommendations: The kernel only has 1GB with which to work, which causes it to run out of memory for managing the page tables. I recommended they: Possible. Checking /proc/meminfo can be helpful. - As a first stage, disable the swap. This doesn't make much sense to me. What is it suppose to achieve? Try to turn on the CONFIG_HIGHPTE kernel config options. It puts (some of the) page tables in high memory. - As a second stage - switch to a 64bit kernel Certainly a good idea if possible. Will be faster then CONFIG_HIGHPTE. Also, is there any way to monitor how much kernel memory is in use? It seems that monitoring the "LowTotal" and "LowFree" values in /proc/meminfo may be what I'm looking for, but I'm not sure I'm reading the docs proprely. Basically, you need enough free space in LowFree, for some definition of "enough". Gilad = 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: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh
Muli Ben-Yehuda wrote: 2. Syscall generation - program calls one syscall, you make it call three. Interesting... I assume this is without kernel support (e.g., UML's SKAs patches). I wouldn't be able to call it "user space" if it was. I should point out that, ptrace being ptrace, some level of understanding (and even duplication) of what the kernel is doing was necessary. I can think of no syscall so platform dependent as ptrace. I made every attempt (and I'll talk about that as well) to make the code as free of #ifdefs as possible. Shachar = 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: Second opinion: oom-killer
On Jan 17, 2008 3:53 PM, Shachar Shemesh <[EMAIL PROTECTED]> wrote: > Oren Held wrote: > > > > B. I can't see why disabling the swap would help to AVOID oomkiller? Swap > > should ENLARGE the available memory space; disabling swap might cause > > triggering oomkiller more frequently. Maybe I misunderstood what you meant. > > > The memory I suspect the system is running out of is the memory > allocated for the Kernel's use. It is labeled "Low memory" under > /proc/meminfo. Here is the strange part - the more memory the system > has, the more memory the kernel needs in order to keep track of it all. > On the other hand, the amount of memory the kernel actually has does not > change when you increase the amount of memory. > > Disabling the swap was my attempt to decrease the amount of overall > memory the system has, and thus decrease the memory management memory > requirement. > > As for A, when it is not application memory that the system is out of, > but kernel memory, oom-killer is, for all intent and purposes, killing > processes at random. > > - Oren > > > Shachar > this was discussed some time ago in RH maillist http://linux.derkeiler.com/Mailing-Lists/RedHat/2007-08/msg00121.html I hope it will be useful. Vitaly = 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: Second opinion: oom-killer
Oren Held wrote: B. I can't see why disabling the swap would help to AVOID oomkiller? Swap should ENLARGE the available memory space; disabling swap might cause triggering oomkiller more frequently. Maybe I misunderstood what you meant. The memory I suspect the system is running out of is the memory allocated for the Kernel's use. It is labeled "Low memory" under /proc/meminfo. Here is the strange part - the more memory the system has, the more memory the kernel needs in order to keep track of it all. On the other hand, the amount of memory the kernel actually has does not change when you increase the amount of memory. Disabling the swap was my attempt to decrease the amount of overall memory the system has, and thus decrease the memory management memory requirement. As for A, when it is not application memory that the system is out of, but kernel memory, oom-killer is, for all intent and purposes, killing processes at random. - Oren Shachar = 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: Second opinion: oom-killer
Shachar Shemesh wrote: Gilad Ben-Yossef wrote: - As a first stage, disable the swap. This doesn't make much sense to me. What is it suppose to achieve? It is SUPPOSED to achieve less memory to keep track of. As far as I understand it, the kernel keeps track over which virtual pages reside in which physical location, and therefor swap pages are being tracked not all that differently than physical memory. I might as well have told them to reduce the amount of physical memory to 8GB to achieve the same goal. If a page does not reside in the swap, it is not tracked as a "swapped page frame". If the server work load is such that significant amount of pages are in the swap with 16GB of memory, I'd say Occam's razor suggest you are simply running our of application memory. Basically, you need enough free space in LowFree, for some definition of "enough". That's what I thought. Too bad Munin doesn't track that particular value, nor does top display it. In fact, for a value that has potential to cause so much grief, it is being practically ignored by standard monitoring tools. You can write a Munin plug-in to track LowFree in a two lines bash script :-) Gilad = 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]
Sears and Wal-mart both Selling $199 Linux PC
Thought We would find this interesting. http://www.i4u.com/article14093.html
Re: Gnu make or replacement?
Hi Ira!
On Sunday 13 January 2008, Ira Abramov wrote:
> I'm helping a client here to start a project from almost scratch. it
> involves java servelets for Tomcat, building with MAVEN, a few external
> GPL tarballs that are downloaded from the web, unzipped and compiled (or
> maybe we'll check them into the CVS) and some glue scripts in bash.
>
> Make is the standard, I just wodered how many of you tried rake and
> other tools that compete against it, and have an opinion...
>
Make alternatives I've had some experience with:
1. Module::Build - http://search.cpan.org/dist/Module-Build/ - primarily
intended as a builder for CPAN or CPAN-like Perl distributions. I found it
better and more flawless than ExtUtils::MakeMaker, which ends up generating a
makefile. The developers were helpful with informing me how I can extend it
to do what I wanted to do.
I should note that it's not intended as a general-purpose building tool, but a
domain-specific one for building Perl distributions.
2. SCons - http://www.scons.org/ - a Python-based tool for software
configuration and construction, that does the equivalent of both make and the
GNU autotools. I used it to write the installer for Latemp (
http://web-cpan.berlios.de/latemp/ ).
My impression for it is that it is high-quality, but:
2.1. Required re-inventing many things that alrady existed GNU-Autotools
wheels, using your own custom code.
2.2. Had a lot of available third-party open-source custom code, but it was
hard to tell what works well or not, and finding the right thing.
2.3. Doesn't separate between configuration (e.g "./configure" ) and
construction ("make") and so has to do both over and over again.
3. Cook ( http://miller.emu.id.au/pmiller/software/cook/ ) - it's a superior
make. The main problem I encountered with it was that I was trying to define
a target dynamically and discovered it was not supported and that they were
more make-like.
4. Ant ( http://ant.apache.org/ ) - I did some small Java-related stuff with
it. It worked well, but I didn't push it to its limit and do not consider
myself an expert of it.
5. CMake - http://www.cmake.org/ - I ran into it when building KDE 4. It still
ends up generating makefiles, but otherwise didn't seem too bad. Possibly a
better alternative to the GNU Autotools.
-
I should note that I'm personally still using Module::Build for most of my
Perl projects, and GNU make for most other stuff.
Other lists can be found here:
http://www.shlomifish.org/open-source/resources/software-tools/#build_links
( Knock yourself out. )
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
I'm not an actor - I just play one on T.V.
=
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: Gnu make or replacement?
I've used scons for a small project with a complex build environment. We were very unhappy with the results. I found its design and API quite deficient. Additionally, we've encountered quite a few major bugs that we had to work around. Make, while deficient in its own right, at least works as expected. On Jan 16, 2008 12:59 AM, Maxim Veksler <[EMAIL PROTECTED]> wrote: > On Jan 13, 2008 2:58 PM, Ira Abramov <[EMAIL PROTECTED]> > wrote: > > I'm helping a client here to start a project from almost scratch. it > > involves java servelets for Tomcat, building with MAVEN, a few external > > GPL tarballs that are downloaded from the web, unzipped and compiled (or > > maybe we'll check them into the CVS) and some glue scripts in bash. > > > > Make is the standard, I just wodered how many of you tried rake and > > other tools that compete against it, and have an opinion... > > > > If it's C / C++ code that you will be compiling then scons is bullet > proof, you will need to learn how to wear the vest though... > > > Thanks, > > Ira. > > > > -- > > The cream in your coffee > > Ira Abramov > > http://ira.abramov.org/email/ > > > > = > > 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] > > > > > > > > -- > Cheers, > Maxim Veksler > > "Free as in Freedom" - Do u GNU ? > > = > 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: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh
>I think >I even gave a haifux talk on run-time modification of programs using > ptrace for fun an profit a few years ago. There is surely a profit and a lot of fun around here, but indeed there was a "ptrace - Playing Debugger Chess" lecture by you, http://www.haifux.org/lectures/115/ I don't know who has a profit here (and who has fun...) Rgs, Yossi -Original Message- From: Muli Ben-Yehuda [mailto:[EMAIL PROTECTED] Sent: Thu 1/17/2008 1:08 PM To: Shachar Shemesh Cc: arbel yossi; Haifa linux club; linux-il Subject: Re: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh On Thu, Jan 17, 2008 at 12:45:10PM +0200, Shachar Shemesh wrote: > Fakeroot-ng is a (as far as I know) first attempt to do the things > usually done with LD_PRELOAD using the ptrace mechanism. It was both > the trigger and the root cause of this lecture. Not sure what you mean by "things usually done with LD_PRELOAD?" Certainly ptrace has been used to both trace and modify running binaries, by gdb, strace, dumpmem[1], memfetch[2] and others. I think I even gave a haifux talk on run-time modification of programs using ptrace for fun an profit a few years ago. > The lecture will look at fakeroot, fakechroot, fakeroot-ng and > strace, at varying degrees of depths, mostly because all four chose > slightly different approaches for solving, fundamentally, the same > problem. They did? Sounds like an interesting talk, will try to attend. [1] http://www.mulix.org/dumpmem.html [2] http://lcamtuf.coredump.cx/soft/memfetch.tgz Cheers, Muli
RE: [Haifux] [Haifux Lecture] User space syscall tracing and manipulation - fakeroot-ng by Shachar Shemesh
Hi, Thanks for the clarification; this makes things even more interesting and exiting ! Yossi -Original Message- From: [EMAIL PROTECTED] on behalf of Shachar Shemesh Sent: Thu 1/17/2008 12:45 PM To: arbel yossi Cc: Haifa linux club; linux-il Subject: Re: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh arbel yossi wrote: > Hi, > It is not clear from this post whether the lecture will deal > with fakeroot-ng or not. The Abstract talks about various techniques > but does not mention fakeroot-ng, while the title includes both. > > Regards, > Yossi > Fakeroot-ng is a (as far as I know) first attempt to do the things usually done with LD_PRELOAD using the ptrace mechanism. It was both the trigger and the root cause of this lecture. The lecture will look at fakeroot, fakechroot, fakeroot-ng and strace, at varying degrees of depths, mostly because all four chose slightly different approaches for solving, fundamentally, the same problem. Shachar ___ Haifux mailing list [EMAIL PROTECTED] http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
RE: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh
Hi, It is not clear from this post whether the lecture will deal with fakeroot-ng or not. The Abstract talks about various techniques but does not mention fakeroot-ng, while the title includes both. Regards, Yossi -Original Message- From: [EMAIL PROTECTED] on behalf of Orr Dunkelman Sent: Thu 1/17/2008 10:15 AM To: Haifa linux club; linux-il Subject: [Haifux] [Haifux Lecture] User space syscall tracing andmanipulation - fakeroot-ng by Shachar Shemesh Next Monday, 21th of Janaury, at 18:30 the Haifa Linux Club, will gather to Shachar Shemesh's lecture about User space syscall tracing and manipulation - fakeroot-ng Abstract Various techniques will be shown for wrapping another program's system calls. All techniques employ user-space only technology. This will range from the trivial (LD_PRELOAD) to the sophisticated (PTRACE+trampoline code). We will also discuss the various advantages and disadvantages of each technique. == We meet in Taub building, room 6. For location information see: http://www.haifux.org/where.html Attendance is free, and you are all invited! == Future Lectures: Crawling in Lightning Everybody! 11/2/2008 Tapping into the Fountain of CPUs---On Operating System Support for Programmable DevicesMuli Ben-Yehuda 25/2/2008 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 [EMAIL PROTECTED] -- Orr Dunkelman, [EMAIL PROTECTED] "Any human thing supposed to be complete, must for that reason infallibly be faulty" -- Herman Melville, Moby Dick. GPG fingerprint: C2D5 C6D6 9A24 9A95 C5B3 2023 6CAB 4A7C B73F D0AA (This key will never sign Emails, only other PGP keys. The key corresponds to [EMAIL PROTECTED]) ___ Haifux mailing list [EMAIL PROTECTED] http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
