sr.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 to malice what can adequately be explain
(not the version in port right now but what 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 sinc
may not have
been any 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 exp
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
>> h
o know.
The cost 20 64bit counters in struct devstat (N|R|W|E)*5*8 = 160
bytes, but since devstat is already 288 bytes, that isn't a major
catastropy.
The ability to measure latency precisly should be retained, but it
could be made a sysctl enabled debugging facility.
The %busy crap should b
remember right, 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
agic string editing is probably 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
In message
, 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...@freebsd.org | TCP/IP since RFC 956
FreeBS
gt;> 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.2
er 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 | TCP/IP since RFC 956
FreeB
o 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 committer | BSD since 4.3-tahoe
Neve
In message
, Zhihao Yuan writes:
>On Mon, Sep 17, 2012 at 11:20 AM, Poul-Henning Kamp wrote:
>> My suggest was 100% serious: Assume X11 _is_ the graphical
>> environment, pick a toolkit which is written to work with
>> any window manager, which all good toolkits are, an
In message
, Zhihao Yuan writes:
>On Mon, Sep 17, 2012 at 10:42 AM, Poul-Henning Kamp
>wrote:
>> In message , Lorenzo Cogotti
>> writ
>> es:
>>>Hi,
>>>I was wondering about the possibility of FreeBSD to provide an official
>>>supported graph
In message , 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...@freebsd.org
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-He
In message
, Adrian Chadd writes:
>Holy. Crap. 17 seconds?
>
>Can we please go back to having it take this long? please?
386BSD was even better, and I have a machine that boots it in less
than 15 seconds from power-on...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@fr
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.
ted
their screwup 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 adeq
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 , 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
FreeBSD committer | BSD since 4.3-tahoe
N
In message , 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...@freebsd.org | TCP/IP since RFC 956
FreeBSD com
uint32_t ipv4, h;
h = ipv4 % HASH;
ipv4 /= HASH;
h ^= ipv4 % HASH;
h ^= ipv4 / HASH;
Where HASH was a prime number near to 2^11
However, I cannot rule out that the good results I saw was a result
if RIPE's allocation policy at the time.
--
Poul-Henning Kamp
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 | TCP/IP since RFC 956
FreeBSD committer
roadblock
$F delete 1
# Remove the evidence
# XXX: Even safer: put jail 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 attri
and friends 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
ort 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 adequ
hread.
--
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.
___
freebsd-ha
In fact, it is only on PC 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, o
le who try to compile our
bits on alien 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
ax_t vs. intN_t, so
now I just 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 adeq
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
>> &
printf("%-30s -> %jd -> %s\n", s, (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
.dk/Galep5.html
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
patches/md-alloc_unr.diff
>
>This sounds useful 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 Ka
ly into userland processes.
Now _THAT_ would 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 adequat
In message , 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 | TCP/IP since RFC 956
FreeBS
nly 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 since RFC 956
FreeBSD committer | BSD
one
>per-process for static data 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 ex
o in the
callout queue, but instead uses the hardware timer to aim an interrupt
at the next time it needs to wake up.
>>the bios may autonomously change the cpu speed
>
>True. This could be an issue.
Your optimism is cute but misguided.
On most laptops the bios WILL change the CPU
significant number of microseconds, plenty of time
to make strange 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 an
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
mited this fix.
>Hi, Poul-Henning, I think 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
that the blkno is aligned to the start of a sector
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/
ture forward, the right thing to do is to fix UDF 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 a
suspend/resume does 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 expla
to be somebody who
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
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
And yes, changing style(9) is just not worth the time it takes.
--
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.
___
c did too. The only trick is to make sure
>that the IRQs of the cards 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] |
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
>&g
ow early his dev_lock needed?
Far 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 expl
ething convinient 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]
s to try :-)
--
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.
___
freeb
, but I'd like
to review 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
most people just worry about their data if the machine gets
stolen.
--
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
rs welcome.
--
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@f
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
/sessions/exit which I have
never really felt comfortable about. My hope is that I have solved
it by refcounting the tty structure.
So if this is before my changes: "Yeah, known (but rare) issue)"
If after my changes: "D**N!"
--
Poul-Henning Kamp | UNIX since Zilog
quest. :-)
yEHA!
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
e head
technology and Partial Response Maximum Likelyhood decoding you can
write and write and write and you will have 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
here, instead
>of just using part of the key material itself to determine the offsets?
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]
trying to obscure these patterns, as well as the
physical layout patterns 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
[E
and up to the claim of being "spook
>strength".
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 |
did subsequent 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 explaine
und keying
schemes for GBDE based on these technologies.
Poul-Henning
PS: Will you be at BSDcan ? It would be a good chance to corner
a whiteboard and some beer.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
uld assume your
>construction is any better. What 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 PROTECT
infected 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
ing the basic material.
See my paper please.
--
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.
___
sed.
Gee Perry, now you're spreading FUD.
You know perfectly well 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
enough honour
to give me a Cc: so I could have a chance to participate in the
discussion.
As I said in my reply just a second ago, I would very much appreciate
if Roland would take the time to give me a competent review of GBDE,
but he cannot do that as long as he is blinded by the desire to ace
ce,
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 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 gen
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 perfor
rs who live the code. :-)
Start out doing it in userland, it's much easier to work 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.
--
Po
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:
>>>
>>
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 f
the one my users inhabit. That doesn't count to me.
> Instead, he admitted his mistakes and wrote a version 2.
Any qualified, factually correct critique of GBDE will be taken very
serious by me. I am very much looking forward to it. What Roland
has provided is not it.
> Are y
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
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 i
r hood, then I am sure that it would be received with
praise 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 ma
t of bounces from 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 attribu
not bothered to actually
analyse GBDE at all but I heard there were a neck-tie party going
on so I thought'd I'd lend them a hand since it is nobody I know".
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
F
enty years from now.
--
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.
_
r ideas, even if told that they are fools by people
who (think they) know better.
--
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
implify so much that people do not trust the result.
As Einstein said: "As simple as possible, but no simpler".
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
m you which amounts to more
than name-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 b
mselves, we do not need more 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
g the same key, even if it is 256 bits, is a safe design.
You 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
Neve
d that you try :-)
We need more ideas 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 adequat
n metadata to protect yourself against 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 adequatel
ectors individually, ignoring the rest of the
>system.
Yes, but is would be Nsect easier with CGD as the entire thing
unravels at the first sector I break. With GBDE I have to
attack them one by one.
And since it is almost a given that any attack on AES will be
statistical in nature, GBDE is m
much useful lifetime out of it. It wouldn't be too much work to
do it however.
--
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 explain
n GBDE, it is obvious that it would
benefit boths parties to make the CGD 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
[
1);
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
rd manufacturers start using it.
>>
>>Saul,
>>
>>Please try to do as Mike says, 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 Free
their evenings.
12. Research/Coding grants (3/6/12 months) from the FreeBSD Foundation
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
(data here)
> void *moredata;
> size_t 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(
GEOM 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 incompet
e. I.E.
>
> traceroute -s
>
>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]
w hard it would be to enforce source-IP
compliance with the jail restriction ?
--
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 inco
1 - 100 of 654 matches
Mail list logo
