1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices] I: service for ircu
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20I%3A%20service%20for%20ircu&In-Reply-To=">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"000596.html">
11 <LINK REL=
"Next" HREF=
"000598.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices] I: service for ircu
</H1>
15 <B>Kelmar K. Firesun
</B>
16 <A HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20I%3A%20service%20for%20ircu&In-Reply-To="
17 TITLE=
"[IRCServices] I: service for ircu">kfiresun at ix.netcom.com
19 <I>Thu Jun
29 17:
20:
20 PDT
2000</I>
21 <LI>Previous message:
<A HREF=
"000596.html">[IRCServices] I: service for ircu
23 <LI>Next message:
<A HREF=
"000598.html">[IRCServices] I: service for ircu
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#597">[ date ]
</a>
27 <a href=
"thread.html#597">[ thread ]
</a>
28 <a href=
"subject.html#597">[ subject ]
</a>
29 <a href=
"author.html#597">[ author ]
</a>
35 ----- Original Message -----
36 From:
"Andrew Kempe
" <<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">andrewk at icon.co.za
</A>>
37 To:
<<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices at delirious.shadowfire.org
</A>>
38 Sent: Thursday, June
29,
2000 3:
39 AM
39 Subject: Re: [IRCServices] I: service for ircu
45 </I>><i> IRC Services will ALWAYS be able to work with ircd's that it has supported
46 </I>><i> in the past. However, those ircds may not be able to make full use of the
47 </I>><i> features in IRC Services.
49 </I>><i> I hope this makes you feel a lot more comfortable. As I've said in the
51 ><i> Services will always be RFC compatible.
54 Okay, that clears up quite a bit of confusion on my part. Thanks for
58 </I>><i> Hopefully in the future things will become a lot more modular. This should
59 </I>><i> make it easier for a
3rd party development.
62 I would look forward to that.
64 ----- Original Message -----
65 From:
"Scott Seufert
" <<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">anarki at flamebait.org
</A>>
66 To:
<<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices at delirious.shadowfire.org
</A>>
67 Sent: Thursday, June
29,
2000 12:
44 AM
68 Subject: Re: [IRCServices] I: service for ircu
74 </I>><i> I'm FAR from the decision maker as to what ircservices is and isn't
75 </I>><i> capatible with. but I'd like to share a few pennies with you.
77 </I>><i> First, is that ircservices are free of charge, meaning the coder(s) isn't
78 </I>><i> getting paid a dime to code, and such code comes from kindness of heart,
80 ><i> from requests from end users. Please don't confuse my last sentence to
82 ><i> that coders don't value end user input, they do, that's where alot of
84 ><i> and bug fixes are spawned.
86 </I>><i> It's MY opinion that the coder(s) should be allowed to go any direction
88 ><i> wish and the end user should expect at least what the pay for.
91 As a coder I have always valued people's input about my programs. But I
93 that with other peoples programs I should at least be able to state my
95 on how I think they could make a better product, free of charge or not.
99 </I>><i> I am friends with several coders of services. Opus for OtherNet Services,
100 </I>><i> Andrew Kempe, current maintainer of ircservices and I would like to count
101 </I>><i> Andy Church in that group if I only got to know him more, seems that I
103 ><i> see him interact publicly as often. It seems that the majority opinion
105 ><i> GPL coders in general is that their number one issue is that the end user
106 </I>><i> isn't satisfied with what is given to them for free, they always want more
107 </I>><i> and sometimes go as far as demanding more. I'm not saying nor implying
109 ><i> you or anyone associated with yourself or your network is doing such, I'm
110 </I>><i> saying basiclly you can't please everyone. CServe for OtherNet was pulled
111 </I>><i> off of the GPL license with the release of CS6/UW9, Opus tried to sell the
112 </I>><i> code he worked very hard on and nearly
"gave
" the project away, just to
114 ><i> of it. CServe/UWorld is unfortunately no longer available to the public.
116 ><i> or for sale. Opus was pounded because the code wasn't public, so he made
118 ><i> public with the GPL license, then he was pounded because it didn't meet
120 ><i> users demands, so he tried to sell it, and was pounded
10 fold for trying
125 You are indeed correct sir. But it wouldn't do Andrew, Andy, nor any of the
126 other coders/maintainers of the IRC services any good if they did not know
127 what others thought about the direction their programs would take. GPL as
128 many will point out is free as in speech, not free as in beer. What good is
129 it to them if their code is not used at all?
132 </I>><i> I can't do anything shy of admire those that write/maintain GPL Services.
133 </I>><i> They give and give without asking anything in return other than obey the
134 </I>><i> license and to RTFM before asking for support, so why not let them deside
135 </I>><i> what is supported and what isn't? So what if it's harder on a few end
137 ><i> To be blunt, most end users would be without services all together if it
138 </I>><i> wasn't for the efforts of these coders. So lets concider how hard it is on
139 </I>><i> the coders to do multidaemon support.
142 Indeed, I have always respected Andrew and Andy. They have been doing an
143 excellent job at maintaining a widely used piece of code and keeping the
145 of bugs down, with out asking too much from anyone else around them. I
147 back on Esper when Andy would go several frustrating days coding services
149 to get this and that working just so. And yet, the code still comes out
151 readable and for the most part free of bugs. Maintaining software is not an
152 easy choir. I've run in to that problem with my own codings several times
156 ><i> You also have the option to continue a multiple ircd services yourself or
157 </I>><i> work closely with someone that maybe interested/knowledgeable in
158 </I>><i> coding,ircservices is still GPL. So as long as GPL licensing is followed
160 ><i> may spawn your own services off and continue that way. Please bear in mind
161 </I>><i> if it wasn't for kind hearted GPL coders, you would most likely have to
163 ><i> or code services yourself. If you follow this course of action I wish you
164 </I>><i> the best of luck. I hope you are prepared to deal with not only the
165 </I>><i> headaches of coding, but countless hours of end user support, bug fixes,
166 </I>><i> mailing lists, hundreds of emails both commending you and condemning you,
167 </I>><i> visitors trafficing your channel on your net looking for support and/or
169 ><i> to install services for them because they didn't RTFM. I wish you luck,
171 ><i> only for the fact that I have no ill feelings toward one that tries to
173 ><i> a difference, but I wish you luck because you WILL need it ...
176 Again, you are correct. Because of the GPL I could port the services back
178 an older/different IRC daemon. My problem with this is that with my own
180 in the works, I've found that I've had to devote much of my time to it
182 of Services. Push come to shove, I could have always used an older version
183 performing bug fixes as needed, but then I would lose some of the newer
185 of the up coming versions. I used to know a good portion of the services
187 back when they were on
2.x and to a limited amount
3.x.
4.x has some
189 changes in the way the message handling is done, and I'd have to sit down
191 figure it out, but this would just take some time, and I could be on my
196 </I>><i> Secondly, if you pin point a specific IRCD type you can have it work even
197 </I>><i> closer be it is only coded for said daemon, it would only have to support
198 </I>><i> the commands from one type instead of many. This makes services smaller,
199 </I>><i> faster and seemingly more seamless than multiple ircd support (which was
200 </I>><i> Andy Church's original plan). That plan being to have good quality non
201 </I>><i> bloated ircservices. I personally like one IRCD support,
99% performance
203 ><i> one daemon to me is far more valuable than
80% performance on multiple
204 </I>><i> daemon support.
207 Egh, to a limited extent. Last time I looked, the code that's not needed
209 other IRCD's are blocked out with IFDEF's, so the only real time penalties
211 be with compiling. The only thing that would be smaller to any great amount
212 would probably be the source code.
215 </I>><i> What did I gain?
216 </I>><i> I didn't have to write services myself
222 </I>><i> What did I loose?
223 </I>><i> I had to use/switch the recommended daemon (which I didn't have to write
227 </I>><i> Over all, I lost nothing.
230 Except for the point that I mentioned, which was stability on your network.
231 Granted my conceptions about the Bahamut code might be misplaced, they may
232 have made some significant improvements in that department sense I had last
233 used Bahamut; however, those are my experiences.
235 I would like to state two things though. One) The message I did send was in
237 very much my opinion, and a mis-interpretation on my part of Andrew's
239 message. Two) I feel I might wish to apologize if that message seemed at
241 inflammatory, this was by far _NOT_ my intent in the slightest. I was
243 expressing a concern I had, I also had, nor do I, or will I have any
245 of
"demanding
" that the current maintainers of Services do anything that I
247 I haven't hired them, and I'm by far not their source of breed and butter.
249 something happens where I absolutely cannot use the code, then I will simply
250 write my own. But why re-invent the wheel?
252 On the other hand, I think you confuse me with someone that constantly needs
253 assistance with getting services to just merely run and someone that assists
254 in maintaining the code. While I do in fact run Services on my own network,
256 also in the past (though not to any large extent) made suggestions,
258 and some code snippets in an effort to help make this program better.
260 the need arise, and Andrew or Andy needed any additional help with coding,
262 I could provide them, I'm more than willing to do what I can.
264 In closing I would like to reiterate that this is an apology, and that I
266 no intention of starting a flame war. (This is not an appropriate place for
268 things) But I think we are both guilty of not looking before we leaped.
270 (Sorry about the long message folks)
275 ---------------------------------------------------------------
276 To unsubscribe, send email to
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org
</A>
277 with
"unsubscribe ircservices
" in the body, without the quotes.
286 <LI>Previous message:
<A HREF=
"000596.html">[IRCServices] I: service for ircu
288 <LI>Next message:
<A HREF=
"000598.html">[IRCServices] I: service for ircu
290 <LI> <B>Messages sorted by:
</B>
291 <a href=
"date.html#597">[ date ]
</a>
292 <a href=
"thread.html#597">[ thread ]
</a>
293 <a href=
"subject.html#597">[ subject ]
</a>
294 <a href=
"author.html#597">[ author ]
</a>
projects / irc.git / blob