Yes.
OpenBSD uses notice level of message information in its default syslog.conf which has a higher priority than info. Therefore, you need to adjust the syslog configuration file to enable info level.
If you want to simply change notice to info, change /etc/syslog.conf like this:
-*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages
+*.info;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messagesThis is a good question.
I thought a lot about using plugin per server at first, this will add more flexibility about using different plugin configuration per server but will also be a huge pain to maintain for the user. Because a lot of people will use an only one irccd instance and server, I prefer to keep plugins globally and not per server basis.
This also means that by default, all plugins will be enabled on all servers and channels but it can be easily filtered with the irccd rule system.
Example:
# Block plugin xyz entirely.
rule drop {
plugins "xyz";
}
# Now enable on desired channels.
rule accept {
servers "myserver";
channels "#mychannel";
plugins "xyz";
}Because Javascript is a very light language easy to embed. The irccd implementation uses duktape.
See also question below.
No, there are plenty of bots which support your language.
!foo !bar?Absolutely no, and will never. The special onCommand
event is dedicated to specific plugin.
Internally, when a user writes a message like
!stats hello (assuming that command char is ‘!’), then
irccd will search for the plugin stats and pass the trailing
text to the plugin command.
In that way, the plugins will never conflict on
onCommand. This security is called plugin namespaces. By
the way, this does not make sense and I don’t know many bot which
support this “feature”.
Remember, IRC plugins are not shell commands that you can pipe one to another.
No, plugins should be independant.
There are no ways to require a plugin. However, you can still verify
if a plugin is loaded via the Irccd.Plugin.info function
and eventually load it using Irccd.Plugin.load
Nobody use DCC.
Irccd is encoding agnostic just as the IRC protocol. If the server send UTF-8 messages, then irccd will pass these UTF-8 encoded messages to the plugins.
Be sure to set a different identity (with different nickname and username) because irccd is a registered nickname.
The definition of bloat is quite subjective.
In some aspects it may be considered as a bit too complicated for an IRC bot but is still quite minimal.
Because irccd offers a runtime controllable mechanism with lots of commands (32 at this time of writing), it increases the total number of lines of code. Please also note that irccd is excessively tested. We could argue that a lots of these command may be unneeded but I like that I can keep the daemon running for months without having to shut it down and restart it to change its nickname.
The Javascript glue code also requires more than the half of the code base to bind the C code to the Javascript interpreter. Disabling Javascript reduces the total code by more than 60%.
But in other hand, irccd still follows the UNIX philosophy of doing minimal things and be extended by the user externally through plugins. It also tries to stick to POSIX and use as much as possible simple and clean code. By itself, irccd’s responsability is to poll IRC events, call plugins and hooks and that’s it.
Yes, technically speaking UNIX daemons may have a name
bard and an optional utility barctl without
the trailing ‘d’ to control the daemon. But since irccd has already two
‘c’, irccctl would be annoying to type especially since having three
identical consecutive letter is unusual. So as an exception, the utility
is named irccdctl rather than irccctl.
Irccd only drinks white beer and French cognac.