Hi,
Well, I've done this before. More than once. I'm glad that you've
stuck through helping me understand what nc is doing; I'm
unfortunately busy doing other things
What you end up doing is:
* tracking the state of the two sockets, both for read EOF and write EOF;
* whenever you get an EOF from
On Tue, Jul 23, 2013 at 04:44:18PM -0700, Yuri wrote:
> On 07/23/2013 16:31, Mateusz Guzik wrote:
> >Of course then you may have some unnecessary separation but that I
> >believe can be simply worked out if it turns out to be problematic.
>
>
> jail would completely separate two systems. In my ca
In message
Adrian Chadd wrote:
>Right, and your patch just stops the shutdown(), right?
The shutdown that occurs when EOF is encountered on stdin, yes.
>Rather than
>teaching nc to correctly check BOTH socket states before deciding to
>close things.
In effect, nc *is* currently "checking bot
On Jul 23, 2013, at 4:31 PM, Mateusz Guzik wrote:
> On Tue, Jul 23, 2013 at 04:17:02PM -0700, Yuri wrote:
>> Currently, mount directories as shown by mount(8) command and
>> /compat/linux/dev/mounts from linprocfs(5) still show the original
>> mount points as other non-chrooted processes see.
>>
On 07/23/2013 16:31, Mateusz Guzik wrote:
Of course then you may have some unnecessary separation but that I
believe can be simply worked out if it turns out to be problematic.
jail would completely separate two systems. In my case this app also
communicates through files that it creates and
On Tue, Jul 23, 2013 at 04:17:02PM -0700, Yuri wrote:
> Currently, mount directories as shown by mount(8) command and
> /compat/linux/dev/mounts from linprocfs(5) still show the original
> mount points as other non-chrooted processes see.
> So, when some program run under chroot tries to read the m
Currently, mount directories as shown by mount(8) command and
/compat/linux/dev/mounts from linprocfs(5) still show the original mount
points as other non-chrooted processes see.
So, when some program run under chroot tries to read the mount points
and do something with them it would likely fail
At 2500 Hz, the tick rate increases by 1 Hz per cycle. There was mention of
a patch that would allow the rate to be as high as 40k without this effect.
--I'll post the link as soon as I find the mailing list thread--
Will this patch work with the current available releases?
On Thu, Jul 4, 2013 at 1:37 PM, Jia-Shiun Li wrote:
> ok anyone can help test and review this patch?
>
> It will allow cpufreq to be removed from kernel conf, loaded and
> function correctly as kernel module. I've tested it ok on my own
> i5-3450.
>
> It removes get_features method definition from
9 matches
Mail list logo
