On 10/20/13 21:54, Theo de Raadt wrote:
Indeed, the interpreter is not passed to execve. That's why I used
'get executed'
instead of
'are executed'
though the difference might not be clear.
The kernel loads the interpreter, and the code of that interpreter
gets executed. So,
I don't get what's wrong with running execve on it. In all cases,
someone can load it through another executable.
Using ld.so does not imply execve'ing it.
If I have an interpreter that I chmod as exec-only, I want this
interpreter to be world-loadable without thereby letting other
users
On 20/10/13(Sun) 12:09, Jeremy Evans wrote:
On 10/20 03:52, Martin Pieuchot wrote:
[...]
Thanks for responding. Here's a new diff that incorporates most of your
suggestions. Unfortunately, using the existing quirks infrastructure
doesn't work correctly, because the quirks API is based on
On Mon, Oct 21, 2013 at 12:04:14AM +0200, Martin Pelikan wrote:
Hopefully the third time does the charm.
The previous union approach to altq/newq bits was wrong, because
switching back and forth was racy. This new diff then concatenates
these structures like [ifqueue, hfsc_if, altq-bits],
* Claudio Jeker cje...@diehard.n-r-g.com [2013-10-21 11:20]:
Can't we not just nuke altq? It is going to die anyway so why try to keep
it alive?
no, sorry.
as much as keeping it was a mistake (wearing my programmer hat), the
painful work has been done already, and the feedback i got on it is
On Mon, Oct 21, 2013 at 12:45:58AM +0200, Martin Pelikan wrote:
Obviously, our locale support still sucks, this patch is mostly
providing the API for filling the blanks later.
Which blanks exactly? Locale features we don't have, such as collation?
Yes. The features why for
Indeed, doing collation properly (i.e. with Unicode, not just 8 bit
characters like FreeBSD does) really is a non-trivial effort.
It requires some expertise in linguistics and a solid understanding
of the unicode standard. You'd need to make use of something like ICU
(icu-project.org) to
On Mon, Oct 21, 2013 at 02:14:32PM +0200, Martin Pelikan wrote:
Applications don't care where a symbol comes from.
Build scripts and Makefiles might expect them to be in libc and
would need to link an additional library, but that's trivial to do.
For all such ports? Ok then :-)
How many
On Mon, Oct 21, 2013 at 02:14:32PM +0200, Martin Pelikan wrote:
Indeed, doing collation properly (i.e. with Unicode, not just 8 bit
characters like FreeBSD does) really is a non-trivial effort.
It requires some expertise in linguistics and a solid understanding
of the unicode standard.
On Mon, Oct 21, 2013 at 09:05:04AM -0500, Vladimir Támara Patiño wrote:
I agree full Unicode support is desirable, but IMHO having 8 bits
collation is better than nothing (for example withouth it spanish
speakers have to
see ñ, á and other special symbols at the end of sorted results in
On Fri, Oct 11, 2013 at 11:46:39PM +0300, Artturi Alm wrote:
On 10/11/13 20:39, Markus Hennecke wrote:
On Sat, 5 Oct 2013, Artturi Alm wrote:
Current version attached, extract to /sys/arch/armv7 and read the short
notes file, no more out of allwinner/ patches needed thanks to armv7.
A20
Hi tech --
Here's a diff to replace some backwards compat calls with their
new calls. The rest were long replaced; I'm assuming these went
unnoticed because they're both under an
#ifdef OCTEON_ETH_DEBUG
This was pointed out by William Orr will AT worrbase ! com in a
private email.
OK?
~Brian
On 10/21/13 18:04, Jasper Lievisse Adriaanse wrote:
On Fri, Oct 11, 2013 at 11:46:39PM +0300, Artturi Alm wrote:
On 10/11/13 20:39, Markus Hennecke wrote:
On Sat, 5 Oct 2013, Artturi Alm wrote:
Current version attached, extract to /sys/arch/armv7 and read the short
notes file, no more out of
Le 21/10/2013 09:38, Theo de Raadt a écrit :
I don't get what's wrong with running execve on it. In all cases,
someone can load it through another executable.
Using ld.so does not imply execve'ing it.
If I have an interpreter that I chmod as exec-only, I want this
interpreter to be
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode when
otherwise nothing would be printed. The only use case I can think of
is did I kill the
On 10/22/13 02:09, Ted Unangst wrote:
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode when
otherwise nothing would be printed. The only use
On Tue, Oct 22, 2013 at 02:34, Alexander Hall wrote:
On 10/22/13 02:09, Ted Unangst wrote:
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode
Hey tech@
Here's a patch that adds octeon's onboard rng chip as a source of
entropy. Currently I fire this off every second, which neither seemed to
increase the load on my ERL or produce duplicate outputs.
This patch also maps out the rnm register which controls the status of
the rng and
18 matches
Mail list logo
