vndb/yhdev
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

ncdc 1.13 released + misc changes

Browse source
This commit is contained in:
Yorhel 2012-08-16 15:05:46 +02:00
parent 1ac0600f93
commit 874e1825ec
10 changed files with 103 additions and 53 deletions
Download patch file Download diff file Expand all files Collapse all files

67
dat/ncdc-faq
View file

@ -22,10 +22,23 @@ positive things about it. Has not seen any recent development, either.
=head2 Why did you start from scratch? Why not use the DC++ core?
There are many reasons why I chose not to use code from existing projects, but
all of them boil down to the following two: 1) I am a control freak, and 2)
personal preferences. That is the short answer. The long answer will require a
full article, and I don't feel like writing that much at this point. >_>
There are several reasons why I chose not to use code from existing projects,
but the two most important reasons are the following: 1) I am a control freak,
and 2) personal preferences.
B<Control freak:> I have no idea how to create an interface to a protocol if I
don't know the overall design and all the tiny details of the actual protocol
I'm working with. And what's a better way to get used to a protocol than by
writing everything yourself? Then there's some other advantages to
reimplementing everything: I get to choose the library dependencies and the
memory/CPU efficiency trade-offs, and I am not limited by an existing
implementation that needs quite a few modifications to achieve what I want.
Most of the "special features not commonly found in other clients" mentioned on
the L<homepage|http://dev.yorhel.nl/ncdc> are a direct result of this.
B<Personal preferences:> These are simple: I rather dislike C++ and working
with other people's code. Working with other people's C++ code isn't exactly
something I wish to spend my free time on.
=head2 What protocol features does ncdc support?
@ -48,52 +61,40 @@ up-to-date client that still uses any of these features.
=head2 This "Generating certificates..." is taking ages!
When starting up ncdc for the first time, it will need to generate a TLS
certificate. If you're on Linux, some versions of GnuTLS may use C</dev/random>
to obtain random bytes. Unfortunately, this can be horribly slow, and in
extreme cases it may take up to an hour before the certificate has been
generated. GnuTLS does not provide a way to use a faster but less secure
certificate. If you're on Linux, older versions of GnuTLS may use
C</dev/random> to obtain random bytes. Unfortunately, this can be horribly
slow, and in extreme cases it may take several hours before the certificate has
been generated. GnuTLS does not provide a way to use a faster but less secure
alternative, so here are some tips to speed it up or cheat a little.
B<Speed it up:> If you're on a desktop, the general advise is to do something
else on the background so that Linux can generate more data. For example, move
your mouse around a bit, go do some web surfing or play a game. Any activity
might help. If you're on a server, you could start transferring some large
data over the network.
might help. If you're on a server, you could try transferring some large data
over the network.
B<Cheat:> There is also another way to "generate" randomness without waiting
for too long: You can feed some bytes from C</dev/urandom> back to the system
by running the following command as root: C<dd if=/dev/urandom of=/dev/random
bs=512 count=1>. You might have to run that command multiple times to complete
the certificate generation, but certainly no more than about 5 times or so.
Note that this solution weakens the security of the certificate by a bit. For
ncdc that doesn't matter at all, but if you have other applications reading
from C</dev/random>, then the security of those applications is also affected.
Unless you happen to be running something that absolutely requires ulta-secure
random numbers, this trick should be perfectly fine.
B<Cheat:> If you have root access, you can probably trick GnuTLS by temporarily
replacing C</dev/random> with something else. For example, run C<mv /dev/random
/dev/random.old && ln /dev/urandom /dev/random> as root, then start ncdc as you
normally would, let it generate the certificates, and then restore your
modifications with C<mv /dev/random.old /dev/random>.
=head2 Ncdc crashes a lot!
Since version 1.10, the following crashes are possible:
Since version 1.13, the following crash is still possible:
=over
=item * You're using an old GnuTLS version (< 2.10 or so, you can check this
with C<ncdu --version>), and you have tls_policy enabled. To fix this, upgrade
GnuTLS or C</set tls_policy disabled>. (Bug L<#11|http://dev.yorhel.nl/ncdc/bug/11>).
=item * You're running ncdc on an old system. FreeBSD <= 8.0 and Mac OS X <=
10.5 are known to be problematic. To get around this, upgrade your system or
bug me hard enough to come with a fix within ncdc. (Bug
L<#14|http://dev.yorhel.nl/ncdc/bug/14>).
=item * You were typing a C</search> command but forgot to provide a query.
This crash will be fixed soonish.
=item * You're using an old GnuTLS version (< 3.0, you can check this with
C<ncdu --version>), and you have tls_policy enabled. To fix this, upgrade
GnuTLS or use C</set tls_policy disabled>. (Bug
L<#11|http://dev.yorhel.nl/ncdc/bug/11>).
=back
If you're running an older version of ncdc, please upgrade! If your ncdc is up
to date and still have a crash not described here, please report a bug.
to date and you still have a crash not described here, please report a bug.
=head2 Ncdc uses too much disk space!