On Fri, Apr 18, 2014 at 08:23:11PM +0200, Markku-Juhani Olavi Saarinen wrote:
Agreed. AES is worse if you don't have AES-NI.
It has been there on all new systems purchased in some last 3 years,
so I would *guess* that it would be 50% of systems fielded out
there.
It hasn't been there on
On Sat, Sep 28, 2013 at 05:56:50PM +1000, matthew green wrote:
ps: I had been meaning to rant like this for some time, your message just
provided the incentive today!
:-)
i will note that i'm also a fan of using -o async FFS mounts in
the right place. i just wouldn't do it for a file
On Mon, Dec 10, 2012 at 09:36:35AM -0600, David Young wrote:
What do people think about setting stricter guidelines for using the
C preprocessor than the guidelines from the past? Example guidelines:
The C preprocessor MAY be used for
1 Lazy evaluation: ...
2 Lexical manipulation: ...
On Tue, Dec 04, 2012 at 11:42:04PM +0700, Robert Elz wrote:
Even chroot isn't a problem, unless you're tempted to view it as some
kind of security mechanism. It really isn't - it is just namespace
modification. Sure, by modifying the filesystem namespace a bunch
of simple security
On Sun, Nov 25, 2012 at 11:47:14PM +, David Laight wrote:
On Sun, Nov 25, 2012 at 07:54:59PM +, Christos Zoulas wrote:
Does everyone agrees on this interpretation? If we do, next steps are
- describe threats this introduce to chrooted processes
Given a chrooted process would
On Sat, Jul 21, 2012 at 07:12:15PM +0200, Edgar Fuß wrote:
I don't know whether this is a disklabel(8) or disklabel(5) or
disklabel(9) problem.
You have to use gpt(8) for disks which have more than 2^32 sectors,
I think, as the disklabel format does not allow them.
--
Roland Dowdeswell
On Sat, Feb 11, 2012 at 07:12:32PM -0500, Mouse wrote:
(Note that while there may be no use for #2 in userlevel code, unless
perhaps if we add an fexecve() call, having it would be convenient in
the kernel.)
fexecve() makes a lot of sense too. So would an flink(), and indeed f*
On Sun, Jan 01, 2012 at 07:05:06PM +0100, Emmanuel Dreyfus wrote:
I intentend to use it to hunt bugs for NetBSD FUSE. Without any
surprise, there are a lot of failures, but I am a it surprised to see
that NetBSD UFS fails the same tests most of the time.
To give an exaample, the script
On Tue, Aug 02, 2011 at 08:52:56AM +, Emmanuel Dreyfus wrote:
On Mon, Aug 01, 2011 at 07:20:30PM +, David Holland wrote:
Sure. But what does it actually do, such that if you have a symlink it
doesn't work to copy the symlink instead of hardlink it?
That would probably work for
