Re: spam (was: re: code duplication)
leo_...@volny.cz writes: > > Lesson: never configure a public machine to misbehave. People might be > trying to get work done and take offense if they're stopped in that rude > manner (just a huge delay, 'permission denied' and closing the connection > would've IMO certainly sufficed). Excuse me, I apologise to butt in on what clearly of great importance to the future development of OpenBSD but I've not really been paying this argument much attention and I want to clear something up. Is this farce all because you're upset that a machine insulted you? Matthew
fu: spam (was: re: code duplication)
I wrote: > Look at the uproar it created here... Okay *sigh*, I can see how this can be misinterpreted; what I meant was that someone offended (in this case somewhat unwittingly) created the uproar, specifically, me. I'm never too good to shoot flak at myself, don't worry... --schaafuit.
spam (was: re: code duplication)
Hi, bytevolc...@safe-mail.net wrote: > Just a tip from an outsider. Those are always more than welcome :) > I would suggest you show a little sympathy for those who are getting > spammed by useless Nigerian scammers, cryptovirus authors, and the > like, claiming to be some kind of "Head of Financial Business > Management Department Business Managing Director" or some other sort of > made up title. Yeah, that's why I normally use a maildir w/ a notification filter -- I don't get alterted if the message contains certain terms. And at the end of the day, it's easy to get rid of such messages using something along the lines of 'fgrep | cut | xargs rm'. Having to go through them with mail(1) must be a real horror... > It would do you a lot better than whinging over a generic piece of text > that wasn't directed specifically towards you anyway, and then calling > people names, That's your misconception, right there. I called the machine a jerkass, and whether its admin is or not remains to be seen (I sent him an apology, just in case he indeed took it personally, but I'm still awaiting a potential answer). > then whinging when your behaviour gets called out. Lesson: never configure a public machine to misbehave. People might be trying to get work done and take offense if they're stopped in that rude manner (just a huge delay, 'permission denied' and closing the connection would've IMO certainly sufficed). Look at the uproar it created here... > If I received the same piece of text, the first thought would be that > at least the OpenBSD mailing list maintainer thinks the same way as I > do about spammers. That they should die in hell, or worse? Sure I agree! But not at the expense of breaking e-mail in any manner. Then the forces of evil just win. > I even had a recent spammer impersonate Theo de > Raadt! That doesn't sound like a spammer to me, that sounds personal. Was it in bulk? > This is why the OLPC rubbish that went on about a decade ago did not > sit well with me. 'cause every child might be a potential suicide bo^W^Wspammer? :X Though I agree w/ you that it's rubbish. --schaafuit.
Re: code duplication
Just a tip from an outsider. I would suggest you show a little sympathy for those who are getting spammed by useless Nigerian scammers, cryptovirus authors, and the like, claiming to be some kind of "Head of Financial Business Management Department Business Managing Director" or some other sort of made up title. It would do you a lot better than whinging over a generic piece of text that wasn't directed specifically towards you anyway, and then calling people names, then whinging when your behaviour gets called out. If I received the same piece of text, the first thought would be that at least the OpenBSD mailing list maintainer thinks the same way as I do about spammers. I even had a recent spammer impersonate Theo de Raadt! This is why the OLPC rubbish that went on about a decade ago did not sit well with me. On Sat, 26 Aug 2017 17:53:27 +0200 wrote: > Hi, > > dera...@openbsd.org wrote: > > Then please demonstrate your sensitivity by stopping use of the > > OpenBSD project's mailing lists. > > Oh? Who's the thin-skinned one, now? > > > Obviously what I'm saying isn't a personal insult. > > I didn't even know his name, still don't know his e-mail addr, and > certainly didn't send a message to postmaster yelling at him that he's > a jerkass. I just referred, in passing, to his mail swerver's > behavior. > > That is all. > > > I just came > > to the conclusion you are a loudmouthed jackass. > > Okay, if I infer what you mean correctly: no, I did not mean that Todd > is necessarily a complete jerkass, just 'cause he (indirectly) behaves > to me that way, just once. > > I thought that was clear. Since it obviously is not, I apologize. > > > So go away. > > *shrugs* I suppose I can forget about you taking a look at my problems > with the wdc_pcmcia code, then. > > --schaafuit. >
re: code duplication
Hi, dera...@openbsd.org wrote: > Then please demonstrate your sensitivity by stopping use of the > OpenBSD project's mailing lists. Oh? Who's the thin-skinned one, now? > Obviously what I'm saying isn't a personal insult. I didn't even know his name, still don't know his e-mail addr, and certainly didn't send a message to postmaster yelling at him that he's a jerkass. I just referred, in passing, to his mail swerver's behavior. That is all. > I just came > to the conclusion you are a loudmouthed jackass. Okay, if I infer what you mean correctly: no, I did not mean that Todd is necessarily a complete jerkass, just 'cause he (indirectly) behaves to me that way, just once. I thought that was clear. Since it obviously is not, I apologize. > So go away. *shrugs* I suppose I can forget about you taking a look at my problems with the wdc_pcmcia code, then. --schaafuit.
Re: re: code duplication
> > P.S. > > There is no good reason to insult Todd > > I don't know him, I might've heard of him once. Needless to say, the > insult obviously wasn't personal. > > > for running spamd(8), which > > is a standard tool and less annoying than some others. > > How do you find 'Hello, spam sender. Pleased to be wasting your time.' > anything but a grave insult to someone who takes the trouble to manually > send e-mail? > > > Managing > > completely open mailing lists is a very difficult, a tiresome, and > > a thankless job, in particular for popular lists like the OpenBSD > > ones, and i'm quite glad the service has been running so smoothly > > all these years. > > I do appreciate that, and I don't complain much if messages get delayed > because of it. > > But when I take the time and effort to not bother people with mangled > subject lines, and I'm just called a spammer and effectively dismissed, > then I call the responsible admin a jerkass for it. > > 'cause that's the feeling it evokes in me, even if it's through the > machine. Then please demonstrate your sensitivity by stopping use of the OpenBSD project's mailing lists. Obviously what I'm saying isn't a personal insult. I just came to the conclusion you are a loudmouthed jackass. So go away.
re: code duplication
Hi, schwa...@usta.de wrote: > there isn't the one answer that fits all situations. > > The goal in this respect is simplicity and maintainability. Yup. > Often, it is simpler to maintain two copies of similar code. > For example, the libc and kernel implementations of malloc(3) > and malloc(9) are distinct. Reacharound between kernel and > userland sources is usually a bad idea, causing #ifdefs, > confusion, and bugs, but not simplicity. In case of system routines like malloc() the seperation is not only justifiable: it's obvious, at least to a degree. In general, any routines that use syscalls would have to be excluded in the first place :) > Duplicate code *is* > maintainable if you don't overdo it. Yeah, and if it's fairly obvious where other copies would reside. > When a new type of bug > is found, OpenBSD developers have a habit of scanning the complete > tree to see whether similar bugs lurk at other places, too. I'm very much aware of that :) > Often, it is simpler to create a library for functionality that has > become stable enough and that has come into use at many places. > For example, the imsg functions - see imsg_init(3) - were moved > into libutil in 2010, after several years of development and > stabilization. A smaller, more recent example is the reallocarray(3) > family of functions in libc. I don't know 'imsg', but reallocarray(3) is a clear example of a routine that's useful to many diff programs, and should thus be externally available. > But making something a library doesn't always simplify things. > Layering and abstraction often increase complexity. Sooner or > later, you detect duplication inside your library, so you make > it use a library which in turn uses a library. CPAN style > interminable dependency chains are not simplicity. Or just > look at the maze of libraries in FreeBSD. A modern solution would be to ditch archive-style libraries altogether and store the individual objects in seperate files. Though while that would certainly help against dependency hell, it wouldn't quite be a guarantee of its elimination... > Everybody has to learn POSIX anyway. Not that POSIX can't have it wrong though... *cough* > But if you invent hundred > additional interfaces abstracting combinations of functionality > that you need here and there, people who want to read and maintain > code suddenly have to learn 100 more interfaces. That is not > necessarily simpler. Of course not. Though if the set of library objects follows a consistent naming scheme, and the manual pages are all there, it might not be so bad. The thing I'm really wary of is preprocessor macros. Even with a manual page, I more than often find '$x expands to $y' to be a sign of impending trouble. Especially if they're nested... > It really depends on the situation, and the balancing act between > abstration and duplication needs experience and taste, not rigid > principles. Depends on how you define 'rigid principles'. A set of good working and organizational habits, based on experience, can certainly be beneficial. As long as it doesn't turn our craft into a religion... > P.S. > There is no good reason to insult Todd I don't know him, I might've heard of him once. Needless to say, the insult obviously wasn't personal. > for running spamd(8), which > is a standard tool and less annoying than some others. How do you find 'Hello, spam sender. Pleased to be wasting your time.' anything but a grave insult to someone who takes the trouble to manually send e-mail? > Managing > completely open mailing lists is a very difficult, a tiresome, and > a thankless job, in particular for popular lists like the OpenBSD > ones, and i'm quite glad the service has been running so smoothly > all these years. I do appreciate that, and I don't complain much if messages get delayed because of it. But when I take the time and effort to not bother people with mangled subject lines, and I'm just called a spammer and effectively dismissed, then I call the responsible admin a jerkass for it. 'cause that's the feeling it evokes in me, even if it's through the machine. --schaafuit.
Re: code duplication
Hi, there isn't the one answer that fits all situations. The goal in this respect is simplicity and maintainability. Often, it is simpler to maintain two copies of similar code. For example, the libc and kernel implementations of malloc(3) and malloc(9) are distinct. Reacharound between kernel and userland sources is usually a bad idea, causing #ifdefs, confusion, and bugs, but not simplicity. Duplicate code *is* maintainable if you don't overdo it. When a new type of bug is found, OpenBSD developers have a habit of scanning the complete tree to see whether similar bugs lurk at other places, too. Often, it is simpler to create a library for functionality that has become stable enough and that has come into use at many places. For example, the imsg functions - see imsg_init(3) - were moved into libutil in 2010, after several years of development and stabilization. A smaller, more recent example is the reallocarray(3) family of functions in libc. But making something a library doesn't always simplify things. Layering and abstraction often increase complexity. Sooner or later, you detect duplication inside your library, so you make it use a library which in turn uses a library. CPAN style interminable dependency chains are not simplicity. Or just look at the maze of libraries in FreeBSD. Everybody has to learn POSIX anyway. But if you invent hundred additional interfaces abstracting combinations of functionality that you need here and there, people who want to read and maintain code suddenly have to learn 100 more interfaces. That is not necessarily simpler. It really depends on the situation, and the balancing act between abstration and duplication needs experience and taste, not rigid principles. Yours, Ingo P.S. There is no good reason to insult Todd for running spamd(8), which is a standard tool and less annoying than some others. Managing completely open mailing lists is a very difficult, a tiresome, and a thankless job, in particular for popular lists like the OpenBSD ones, and i'm quite glad the service has been running so smoothly all these years.
RE: code duplication
Hi, rauldmil...@gmail.com wrote: > On Sat, Aug 26, 2017 at 4:36 AM, wrote: >> The greater the body of code is, the smaller our understanding, or at >> least our ability to grok the code. >> >> Even in the UNIX world, 'duckspeak' code -- just doing what seems right >> without realizing the longer-term implications -- is unfortunately very >> common. >> >> I don't think that we can really afford that in the modern world. > > Could you be more specific? Lack of foresight. (I hope that indeed qualifies as 'more' specific and not 'less'...) > What problem are you trying to solve? Not a single, discrete one. More like a range of potential problems that are, from my pov, just sitting there, waiting to manifest themselves. As fun and useful as it must've been (it predates me! :), we're no longer just playing research on PDPs. The margin of error has decreased enormously since then. How many people use OpenBSD in their firewall? I suppose many. Apart from the inconvenience of applying patches, do we really want to take the risk of sites getting pwned just 'cause we fixed a problem in one place and not in another? And that's just security. Any bit of code is only as decent as the assumptions of the programmer. Isn't it a *little* too easy to assume, that we know what we're doing? I suppose that what I propose, is that we be more sceptical of our own abilities, and act accordingly. By taking into account the flaws of wetware: we're relatively good at invention, but relatively lousy at verbatim repetition. We're good at quick-and-dirty workarounds, but long-term solutions take us a lot more effort (not that they're not worth it! :). A well-designed computer can complement our capabilities. It cannot replace our capabilities, nor can we replace the computer's. To try to do either would be foolish. But then again, we're all fools in the end, anyway =) And then there's the issue of us limiting ourselves to operate within the designs we ourselves create... Sorry if this all sounds trivial, but given the state of a typical piece of (even UNIX) code, I'm reminded of this stuff everyday. I thought it wouldn't hurt to share it. --schaafuit.
FU: RE: code duplication
Sorry for the tyop in the subject line, boy will I be glad to get rid of this $#@$%&! webmail poop that doesn't know how to send a proper reply... Of course, to add insult to injury, I can't manually send the messages either, as the openbsd.org mail swerver decides, on connection, that I'm sending spam and proceeds to try to 'waste my time' by eating my message... rrright, jerkass. --schaafuit.
