View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001562 | unreal | ircd | public | 2004-02-19 11:32 | 2004-02-19 12:05 |
| Reporter | ravenflx | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Summary | 0001562: Feature Integrations | ||||
| Description | I once recently used BIRCD and saw some of the commands would be great if integrated to UnrealIRCD. While UnrealIRCD has a module where you can be notified on a specific command usage, BIRCD has a "OperOnlyCmds" feature which is pretty cool. Also, AngryWolf has a bunch of great modules which would be great if they were integrated aswell. For example, "operpasswords", "netadmins" (which shouldn't be a problem if people knew how to pick proper staff, but still something that is a good precautionary feature), "rmtkl", "rmban", "getinfo", "clones", even integrate the mirc dcc bug? Also "chansno", "cmdflood", "joinpartsno", "tempshun", "operjoin" (oper god? or new "god" flag? -would be great), and even possibly "regexban". All of these are great features and would be great if they were streamlined into UnrealIRCD. If some are questionable or something, there could be a On/Off flag in the conf. The commands are great, and would be better if integrated in the next RC of UnrealIRCD. Would help those who have to load 20 modules aswell ;) Thanks for reading, Joshua | ||||
| 3rd party modules | |||||
|
|
"operpasswords" -> No. This module presents a security risk. Research shows that the majority of failed password attempts are typos. For example my password is "blah" but I type "vlah." Therefore showing the password is foolish as all it will do is lead to people being able to steal passwords. "netadmins" -> No. As you said, pick your staff carefully. If you feel your staff is not trustworthy, then you remove their access. "rmtkl" -> Something of this manner is already planned however it will be done differently so that it is done at the IRCd level and therefore can be highly bandwidth efficient. "rmban" -> No. I don't see why this is useful. "getinfo" -> No. Again, I don't see why it is useful. Sure, you may want to get info about a user/server, but I don't really see why you need such info and why the current methods of getting said info are insufficient. "clones" -> No. I've yet to see a services package that doesn't already have such a feature built in. even integrate the mirc dcc bug? -> If you mean the "antidccexploit" thing, then that will be implemented using the new spamfilter system. "chansno" -> Why is this useful? "cmdflood" -> No. Incredibly memory intensive, and also not truly feasible. Clients expect certain commands to always give certain replies, for example /list or /links. If those replies are not given the client may become confused. "joinpartsno" -> No. The only reason I made this module was the stop people from continually asking for it to be in Unreal. "tempshun" -> Something like this is already being considered. "operjoin" -> Definately not. This defeats the entire purpose of why this feature was removed in the firstplace. "regexban" -> No. It's a nice idea, however it is incredibly memory/CPU intensive (each ban needs to have an allocated regex_t structure which can be 1KB in memory a piece), and most people don't know regex as it is. If you want any/all of these features, then load the modules. The purpose of modules was NOT so that other people could write things and then we stick them in Unreal, the purpose was people could either just implement their own ideas or implement ideas we said no to. Including most of the existing modules directly into Unreal defeats the entire purpose of the module system. |
|
|
Rejected. As for "next RC", you obviously didn't understand what 'RC' is... Anyway, let's get to the point: >80% of these things will never make it into the core because they are totally stupid, highly unethical (operpasswords?? OMG!??!!?? HOW SAD!), have been rejected in the past ("oper god", unkillable opers, operjoin, chansno), or tens of other reasons (speed, code, uglyness, low gain high effort, etc)... Of course some of the things angrywolf made were already planned or thought about before (for example rmtkl [0000840], tempshun [0001526].. and in the past adwords, snomask +N)... (not saying that is bad btw). Things like operonly commands and better high-pricision operlevels were also thought about before but won't be in 3.2*. I guess some things he has atm can be nice but for some strange reason haven't suggested it here before, for example rmban (that's the only example I can give btw.. I don't look into these modules too often).. Anyway, we did put in module support in for a reason... You are free to use these modules (but you won't get support on them from us)... If you decide to load 20 of such modules, that's your decision. |
