be removed
from patch(1)?
See head/usr.bin/patch/inp.c lines 166 to 240 for details.
Yes, that code should be removed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
will become version 0.2).
However, I think these programs should be fixed, rather than put tradcpp
in the src tree.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice
previos FOREACH involved.
TAILQ_FOREACH_FROM(...) ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message 516c71bc.4000...@freebsd.org, Alexander Motin writes:
On 15.04.2013 23:43, Poul-Henning Kamp wrote:
In message 516c515a.9090...@freebsd.org, Alexander Motin writes:
For tuning anything on a non-ridiculous SSD device or modern
harddisks, it will be useless because of the bias you
to measure latency precisly should be retained, but it
could be made a sysctl enabled debugging facility.
The %busy crap should be killed, all it does is confuse people.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
, this was for the case where you had preloaded
multiple images, and the kernel would only auto-discover the first
one.
All things (such as the disapperance of floppy disks), considered
this feature should be removed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP
not a good idea.
Given that /dev is really just a view into GEOMs namespace, one could
argue for GEOM:ada0p3 that that may be going overboard in sematic
correctness.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
In message cagh67wqty4krgwspa5jaht-4hqd4veykley-r3c6k9f5xaf...@mail.gmail.com
, Garrett Cooper writes:
No difference proven at 95.0% confidence
This is the important bit of information...
Thanks for the tip :)!
You're welcome :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p
you have at least 75% of the user population of FreeBSD agreeing
on which window manager we should offer as the default, we can talk
about this.
Until such a consensus exists, this discussion is just a waste of time.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
about this.
so if 76% would decide that FreeBSD should have KDE included in system -
it means that it should?
Just to clarify: when I write offer by default I do not mean cram
down peoples throat.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC
In message blu0-smtp510b16745b704c714268e2d5...@phx.gbl, Lorenzo Cogotti writ
es:
Hi,
I was wondering about the possibility of FreeBSD to provide an official
supported graphical environment.
We already do: It's called X11 :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p
In message CAGsORuAnDs_E=l747+tp95nxjxdonnsqfvfco+xd2hjsj-u...@mail.gmail.com
, Zhihao Yuan writes:
On Mon, Sep 17, 2012 at 10:42 AM, Poul-Henning Kamp p...@phk.freebsd.dk
wrote:
In message blu0-smtp510b16745b704c714268e2d5...@phx.gbl, Lorenzo Cogotti
writ
es:
Hi,
I was wondering about
In message cagsorub4yd8rknlrwmctx16idohwjkd1rnyarb98nwn+pwv...@mail.gmail.com
, Zhihao Yuan writes:
On Mon, Sep 17, 2012 at 11:20 AM, Poul-Henning Kamp p...@freebsd.org wrote:
My suggest was 100% serious: Assume X11 _is_ the graphical
environment, pick a toolkit which is written to work
be nice to have as an option, but I would hate
to have to deal with it, when I squeeze FreeBSD into embedded systems
which have neither graphics outputs nor keyboard or mouse inputs.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD
In message 20120816081336.gb27...@e-new.0x20.net, Lars Engels writes:
386BSD was even better, and I have a machine that boots it in less
than 15 seconds from power-on...
Me too, it's running Linux. ;-)
You should upgrade the OS then... :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus
-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org
In message 201208102249.q7amn8gf066...@fire.js.berklix.net, Julian H. Stacey
writes:
I dont see 1.1.5:
It is not in our VCS because of the USL-BSD lawsuit.
You can find the bits here: http://phk.freebsd.dk/FreeBSD/
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
in their manual.
TL;DR: Which part of compatible doesn't Intel get ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
I would like to point out that all other operating system which has
had this precise problem, have solved it by adding a bootfs partition
to hold the kernel+modules required to truly understand the disk-layout ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
In message alpine.bsf.2.00.1206130909310.73...@wojtek.tensor.gdynia.pl, Wojci
ech Puchar writes:
One of the major slowdowns is that we do all the device drivers
serially synchronously.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
In message alpine.bsf.2.00.1206031022360.55...@wojtek.tensor.gdynia.pl, Wojci
ech Puchar writes:
is it the same possible with USB?
i mean if i can make my laptop to simulate say USB CDROM.
No, the hardware is not up to it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p
-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org
UID/GID spaces.
Filesystems mounted or visible in multiple jails act as shared UID/GID
(sub-)spaces for those jails, but there is now way to avoid that, it's
a direct consequence of the sharing of the filesystems.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
in md(4) disk, rm, remount r/o
rm -rf $jdir/*
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
, it is global rather than per-thread.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
also support in pthread for thread specific storage, which
should be your first choice.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
are implemented ? That
might allow you to.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
like hardware that you can reliably share
a disk between different mutually competitive operating systems.
Most unix-machines don't have a concept of what you call partitions,
and neither did BSD unix until 386BSD introduced it.
Until then: One OS, one disk(-pack|-drive).
--
Poul-Henning Kamp
systems without bmake.
I am not sure if that is a concern we should care about.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
, (intmax_t)t, buf);
If some system introduces int512_t that may not be optimal, but
since printf is a pretty slow operation anyway, I doubt it will
hurt even half as much as the alternative.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD
In message 4debe469.5060...@links.org, Ben Laurie writes:
On 05/06/2011 19:21, Poul-Henning Kamp wrote:
In message 4debc741.1020...@links.org, Ben Laurie writes:
I have therefore resorted to printf'ing any typedefed integer type using
%jd and an explicit cast to (intmax_t):
printf
cast anything that that's typedef'ed to intmax_t and
move on.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
There are various hooks into this product which allows it to be
controlled by programs, I have not used those (yet?)
Recommended,
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
to me. Perhaps ask p...@?
My only worry is that if people start to use this indiscriminantly to
store random collections of numbers, then it is far from the optimal
data structure for it.
Other than that: go for it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
be interesting.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
notice
in reaction to temperature and battery power.
Let me repeat:
[1] In my mind, reworking the callout system in the kernel would
be a much better more neded and much more worthwhile project.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP
like getpid/getgid.
Agreed, that is a good place to start.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
to a per-CPU page.
Rule #3:
The only thing worse than generalizing from one example is
generalizing from no examples at all.
We can add those mappings when we know why we would want them.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP
In message alpine.bsf.2.00.0903272303040.12...@fledge.watson.org, Robert Wats
on writes:
In which case user application threads will need to
know their CPU [...]
Didn't jemalloc solve that problem once already ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
things happen.
You will want to study carefully Dave Mills work to tame the alpha
chips wandering SAW clocks.
Poul-Henning
[1] In my mind, reworking the callout system in the kernel would
be a much better more neded and much more worthwhile project.
--
Poul-Henning Kamp | UNIX since Zilog
In message 49874ca8.5090...@gmx.de, Christoph Mallon writes:
I compiled a list of all local variables in src/sys/ (r188000), which
are only written to, but never read.
Bravo!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD
it should be MFCed before release.
I agree, but I'm ENOTIME.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
to not
access subsectors.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
and use the 512 byte units, so I guess it would be:
offset = dbtob(blkno);
KASSERT(!(offset (bsize - 1)), (suitable diagnostic));
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
not work on SMP systems, including
multi-core laptops.
:-/
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
is into serious bandwidth AND clue.
Should any of you know of a good candidate, please tell them to email
me.
Thanks in advance!
Poul-Henning
PS: Full discretion! The software will be delivered in plain brown IP
packets with no source address :-)
--
Poul-Henning Kamp | UNIX since Zilog
Apologies for this interruption:
If we have any D-Link employees in the audience, please contact me by
private email, thanks!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org
are not shared between the cards or with
any other device.
I suspect it is not the card as much as the driver, but I am not sure.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
too early due to console madness (in syscons I belive).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message [EMAIL PROTECTED], John Baldwin writes:
On Thursday 29 September 2005 02:14 pm, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], John Baldwin writes:
Actually, you would think that it could be initialized either via an early
SYSINIT() or in the init_mutexes() function
for the source encoding?
All filenames in DEVFS are either created from the device driver
'C' source (as a string literal via sprintf mostly) or from userland
as symlink.
So whatever works.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
the patch before it gets committed because there are a
large number of dragons.
In P4:phk_gbde there is the beginning of hw-crypto support through
opencrypto(9), if somebody wants to work on that, get in touch with
me.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org
an encrypted volume
(very hard!) and mounting the root filesystem from an encrypted volume
(possible with pawels patch.
Now of course, if your kernel has been trojaned, you're in trouble, but
then again, most people just worry about their data if the machine gets
stolen.
--
Poul-Henning Kamp
.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org
Resume timer: unknown
Resume on ring indicator: disabled
Isn't there some kind soul who can make sysutils/xbatt (or some other
X11 tool) show the status for the two batteries individually ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since
!
Thankyouthankyouthankyou!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
?
Because if I used part of the key material you would have to change
the location of the lock sectors when you changed the key material.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
no idea if it works or
not. Bad sector forwarding is another issue in this area.
There are commercial companies who have specialized in recovering
deleted data from trackfringes.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
.
GBDE only makes that claim for a cold disk for pretty much the very
reasons you mention.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
of the storage managment (filesystem/
database) beyond the basic rotation, would just slow things down
and not add any incremental security worth it.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers
to that time is not really
relevant.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
this.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd
and more people trying out ideas.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
seem to belive otherwise.
And that's where it ends.
Have a good life.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
ideas, nor more people trying
out ideas; we need less.
Standard, widely analyzed cryptographic algorithms are good.
s/ are good/, when applied with caution and wisdom, are good/
:-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
-calling and hand-waving.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org
bound. But even after removing several orders
of magnitude, that leaves a huge amount of material you can encrypt with
a single key.
Just throwing out a data point.
This would be much more interesting if you qouted the number they will
say ten and twenty years from now.
--
Poul-Henning Kamp
it is nobody I know.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
and thanks of no end.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message [EMAIL PROTECTED], Thor Lancelot Simon writes:
On Thu, Mar 03, 2005 at 08:25:18PM +0100, Poul-Henning Kamp wrote:
To quote David Hume, Never an ought from an is.
I'm Danish by birth so english is only my second language, so I
apologize for mangling it.
That users (who
are they? how
In message [EMAIL PROTECTED], Todd Vierling writes:
On Thu, 3 Mar 2005, Poul-Henning Kamp wrote:
At the time where I wrote GBDE, the best that was offered was CGD (and
similar) and users (not cryptographers!) didn't trust it
Could you back up this claim, insofar that users did not trust cgd
and
saying GDBE is perfect as it is,
Now, there is one thing I have never said and would never say.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
In message [EMAIL PROTECTED], Perry E. Metzger writes:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
Don't let peole like Thor scare you away, progress happens when people
try to follow their ideas, even if told that they are fools by people
who (think they) know better.
They laughed at Fulton
In message [EMAIL PROTECTED], Perry E. Metzger writes:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED], Todd Vierling writes:
On Thu, 3 Mar 2005, Poul-Henning Kamp wrote:
At the time where I wrote GBDE, the best that was offered was CGD (and
similar) and users
with. In
FreeBSD we have something called geom-gate which allows you to
implement disks in userland. I'm sure something similar exists or
can be trivially created in your favourite OS.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
In message [EMAIL PROTECTED], Todd Vierling writes:
On Thu, 3 Mar 2005, Poul-Henning Kamp wrote:
And if CGD is _so_ officially approved as you say, then I can not
for the life of me understand how it can use the same key to generate
the IV and perform the encryption. At the very least two
In message [EMAIL PROTECTED], Thor Lancelot Simon writes:
On Thu, Mar 03, 2005 at 10:15:55PM +0100, Poul-Henning Kamp wrote:
And if CGD is _so_ officially approved as you say, then I can not
for the life of me understand how it can use the same key to generate
the IV and perform
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org mailing
of thinking his arguments properly through and
test his hypothesis. Unfortunately I can no longer offer him financial
compensation for the effort, the DARPA contract is long since closed.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since
that it would take less than one hour to
substitute another algorithm in the GBDE source code.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org
with, but that doesn't mean I am not
interested in a discussion on the subject: just put me on the Cc:.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
do you know that the NIST/NSA review
of AES did not know?
That neither the authors of Rinjdael, its reviewers, nor NIST are
willing to offer a 25 year warranty on it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
various lists I'm not on. I put
my faith in somebody forwarding my replies faithfully onto those
lists ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
key handling an option for
GBDE.
So how about it guys: Instead of spreading FUD, lets work together
and make the world an even better place ?
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org
will be
statistical in nature, GBDE is much more resistant because
there is no two-way leverage on any of the algoritms.
So, I will still claim that you get points for your key handling
and flunk on the disk encryption side.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
);
strvisx(vbuf, buf, ibcnt, VIS_WHITE | VIS_CSTYLE);
printf(%s\n, vbuf);
return (0);
}
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
, it would save a lot of time and windmills
if you would check the facts rather than keep arguing your unfounded
dogma.
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] Real hackers run -current on their laptop.
Go fly a kite, Poul. I'm not interesting
and other deep(er) pockets to help some of the heavy lifting happen.
We're not only in it for the money, but money surely helps.
And I'd like to stress that none of the above requires you to get
permission from the core team, just go out and do it!
--
Poul-Henning Kamp | UNIX since
morelen;
};
What is the proper way of sysctl'ing IN the data from moredata?
I need to make a copy of the sysctl req, but... I'm not sure what
to initialize the 'lock' member to.
Just use the SYSCTL_IN() and ..._OUT() functions.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
friendly:
[...]
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
Otherwise it might fail.
How does traceroute and ping normally determine which source address
to use ? Can't we use that mechanism to default them to the right thing ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
http://people.freebsd.org/~phk/funding.html
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message [EMAIL PROTECTED], Dan Langille writes:
On Thu, 8 Apr 2004, Poul-Henning Kamp wrote:
http://people.freebsd.org/~phk/funding.html
typo :(An before any of you get an
Should be And, not An.
Fixed, thanks!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
1 - 100 of 606 matches
Mail list logo
