On Fri, Mar 21, 2003 at 03:51:16PM +0000, David M. Wilson wrote: > On Fri, Mar 21, 2003 at 02:37:24PM +0000, Lusercop wrote: > > A traditionalist whose idea of programming style is almost as good as djb's. > In the real world, it is often the ugly hack that gets things done. As > for DJB's style of coding, I don't understand most of it myself but > according to some skilled sources, "it's quite nice". Said skilled
I've read bits of it, when I wanted to know in advance that it was going to do what I needed it to do, and the documentation was not up to scratch. Trust me on this, or look at it yourself, but we've already had this discussion here recently. The code isn't either. It's write-only code. CClient, is, IMO, pretty similar. Virtually every line has at least 3 side-effects, and there is no sensible modularisation. > sources are the sort of people I don't get into arguments with, because > I always loose. :) 'lose', or perhaps 'luse'. I have read this stuff, and I'm prepared to hold my opinion on it. I notice that no one replied to my challenge to explain the constants in datetime.c. That's the kind of code we're talking about. > > > If I remember correctly, (and bearing the above comment in mind), said > > > library is designed for static linking, aka: > > > cc -c -o cclient.o ../cclient/cclient.c > > > cc -I../cclient -o myprog $(MYPROG_OBJS) cclient.o > > Yuck. > Yeah, no ./configure. Surprisingly enough, that's not what I'm going "yuck" about. I have a problem with the "compile this thing from outside my source tree to an object file inside my build tree so that I can link it". And, as you're someone with fairly advanced C Compiler options understanding, you'd know that the -I is irrelevant in the situation in which you have it, you need it for building the dependencies of that final line. UNIX has had dynamic linking for well over 20 years, anyone who doesn't use it because he's a "traditionalist" is kidding himself. There are many reasons to prefer it over static linking. > > Oh, I dislike autotools, don't get me wrong, but not including information > > about headers, API and library output *IS* woefully incomplete, by any > > definition of the word. I know of many packages that *don't* use autotools > > and still manage to get this kind of simple thing correct. > As with any build tree, it's a build tree. I try to avoid doing builds > myself now-adays, and know better than to complain when I don't get > someone elses concept. That's an interesting attitude. I don't think it's a useful one, though. Kind of sympathetic magic, almost. > > Oh, absolutely, and I'm also well aware in this case that Dave has them. > > (bloody hell, I'm standing up for Cantrell, what's wrong with me?). > I wasn't attacking Cantrell, I was simply stating a relevant opinion. You quoted his message, it certainly looked like you were. > > Basic linker knowledge should not extend to "what the **** does this > > guy think he's doing with this file". If the C is as badly written as > > Mark Crispin's piece of junk, then you won't have a hope in hell of > > doing anything with it unless you're an expert programmer. > In this case, an end-user (effectively) having trouble installing a > library from source is a good indication of a failure on the part of the > Linux distribution in use. !?!?! Where on EARTH did I say *anything* about Linux? There are many other UNIXes out there, and yes, I use more than just Linux, in fact the main one I use *isn't* linux. I'm certainly not convinced of this assertion though. > If it isn't Linux, then take a look around, there are hundreds of > sources of pre-compiled binaries (although maybe only tens of trustable > sources). Erm, we were talking about building from source, why do you introduce this irrelevant argument. > > > The same could be said for make, a rather neat and portable way of > > > keeping files in sync. > > Hahahahahahahahahahahahahaha > > You are joking, aren't you. Please tell me you are. How many different > > versions of make do you think exist, with their respective bugs. It is > > not actually possible to write a portable makefile that has any kind of > > conditional dependency. At all. > Well done for stating the complete obvious. Would you have laughed like > a child had I said "awk is a pretty portable text extraction tool"? "ha No. You will notice no conditional dependency syntax elements in: http://www.opengroup.org/onlinepubs/007904975/utilities/make.html This means that any such things are inherently unportable. If you'd have come to Schwern's talk on MakeMaker, you'll have heard that one of the biggest problems with it is trying to spit out the right kind of syntax on each individual platform. > ha ha LuserCopOs' awk doesn't let you change the IFS. Oh no, it's > completely importable now." You will also want to notice the "-F" option in: http://www.opengroup.org/onlinepubs/007904975/utilities/awk.html I don't think your point is valid. > > > Cursing people more skilled and/or intelligent than yourself is the > > > easiest thing to do on the planet[0], and just because a package doesn't > > Mark may be more intelligent than me, I'm not sure if he is or not. However, > > his coding "style" leaves exceedingly large amounts to be desired. > Said Jesus to his children. Yes, it's opinion, and...? > > His ability to package software in any kind of sane way appears > > similar. The UW-IMAP server is a disaster area, and C-Client is a fair > > approximation at a guide of how *not* to program. > Once again, it is used successfully all over the place. Dry your eyes > and write a 'better' implementation if you are unhappy with it. I don't use it. Where possible. I occasionally have to support it, however, because people seem to like PINE. I have tried to discourage them. And I don't have the time to "write a better one". That doesn't stop me being disappointed in the currently available software. > > > follow the GNU/Linux empire's way of tar.bz2 + 200k of m4 drivel, > > > doesn't mean it's of poor quality. > > Nobody said that it needed to have autoconf, and a lot of people don't > > like it, including myself. It does, however, seem to me that the C-Client > > code as it stands is indefensible. The build instructions are, as has been > > said already, woefully inadequate. The tar.bz2 argument is a straw man, in > > this case, it's mainly about file size, bzip2 is, quite simply, a better > > compression algorithm than compress. > I never implied David was complaining about the lack of the autotools, > or the packaging format (he didn't even mention this). My point was that Oh, ok, your mail just read like you were. > while c-client's build system and build instructions are unorthodox, it > is not up to the end user to judge it's quality by these factors. The > build system is just that -- end-users should not be building their own > binaries most of the time. In these days of out of a box linux, possibly. That's not to say that I think that using a UNIX is a good solution in those cases. > If you are a user and you cannot build a package, there's a good chance > you shouldn't be trying to in the first place. OK, I agree with you on this. But if many experienced sysadmins find c-client an annoyance, then perhaps there's something in that, no? > > Next you'll be saying that someone using crypt(1) is in the right, > > because they're a "traditionalist", even though the attacks against it > > are well known. > No, that's sacrificing functionality (security) for portability. Why the > hell do you always end up ranting about security? It's my job, as you are no doubt aware, given that you've looked up who I am. It's what I've chosen to specialise in, and it's an area where I have a lot of interests. I was merely pointing out that there are some "traditional" things which are fundamentally broken by design. I would tend to include c-client in that list. I've been involved in reviewing OpenSSL at least, and I tend to review software that I'm going to have to run, even if it's only a cursory glance. As it is, I see many people who think that just changing all the strcpy()s to strncpy()s magically makes their code secure. Or, putting a firewall in front of a network magically makes it secure. I work for a company whose primary interest is in security and secure hosting. > > > [0] I'm guilty of it here -- I guess now that c-client is packaged with > > > compress for portability. > > To provide the most hassle for any sysadmin who has to install it. > Try looking for a gzip or bzip2 binary on a SunOS or IRIX default > install. There's a whole world outside Linux/perl, Matthew. I haven't seen a SunOS install in, what, 6-7 years. Perhaps you mean Solaris. I'm aware of the world outside linux/perl, and bzip2 is actually one of the better pieces of gnu software, it's actually pretty portable, and so I'd be happy putting it onto a solaris box, in much the same way as any other piece of software that I'm installing. What you may also have noticed is that people tend to provide tar.Z and tar.gz too, so that there is a choice. I'm certainly not going to argue that there is One True Way and that there shouldn't be this choice, something that you seem to be advocating. > > No, it just reads as if you don't know what you're talking about. > Don't talk to me. I'll talk to who I like. If you don't like what I have to say then killfile me. I don't mind if you do or don't listen. I do object to being told what and what not to say and when to say it. If you were the list admin, then maybe I'd have a bit more respect for your opinions. > Please don't reply on-list either, a lot of people don't like listening > to you. And some do. Those who don't know how to use their killfiles. If they don't then they can always just press their 'd', delete or other keys for my posts. I merely found what you had to say deeply and offensively luserish, and I launched into an attack of why you were wrong. There are valid points to be debated here, but if you're just going to say "I'm right, don't talk to me anymore", then I think that you lose all credibility in such a debate. If the list admin doesn't like what I write, then it is up to him to say "you shouldn't have said that" or "don't post that". It is not up to you to say "the lurkers support me in email", and therefore you shouldn't post anymore. -- Lusercop.net - LARTing Lusers everywhere since 2002
