Re: [dev] [st] goals / non-goals for st?
you are a compulsive replier, you haven't time to use a computer On Fri, Oct 30, 2009 at 3:24 AM, Uriel wrote: > > On Thu, Oct 29, 2009 at 11:01 PM, frederic wrote: > Example: > http://xinutec.org/~pippijn/files/img/collection/why-transparency-is-evil.jpg > > > > > So sugar is evil, because if one eats too much of it, one may die. > > And make the world a better place as a result. > > > So, I agree with uriel: transparency is for idiots. > > > > Often, drunk people seem to believe that other people are drunk. > > And often idiots are just idiots. > > > > Do yourself a favour: stop calling others idiots. > > Do yourself and the world a favour and go use Gnome, or even better OS X. > > > >>> When I was young I thought hey that looks cool (compared to the usual > >>> terminals on Windows by that time). But when actually using it for a > >>> while it hurts more and the coolness factor becomes obsolete sooner > >>> than later. Perhaps the younger generation has better eyes and can > >>> cope with it for a couple of years, but I haven't seen any serious > >>> programmer that worked with translucent terminals very long... > >>> > > > > I think I'm not younger than you, and I have been working with translucent > > terminals for about ten years on a daily basis. > > And now we have conclusive evidence that using translucent terminals > for extended periods of time damages the brain! > > Thanks for sacrificing yourself as guinea pig for this essential and > fascinating scientific research project. > > > > I think the reason why I've been using them for so long is because I use > > them more for the aesthetics than for the coolness factor. > > Of course, my wallpaper doesn't show some lame anime character, insipid > > landscape or kickass-y car. > > What have you got as wallpaper? A picture of your but? > > > >>> Apart from that, all the other reasons (unnecessary complexity, > >>> unnecessary cpu cycles, etc) are true and I agree. > >>> > > > > I won't argue against that. Suckless software is nice, because it spares > > some resources on my machine, so I can use translucent terminals :) > > > >> > >> If you need the transparency, there are compositing window managers > >> that will do perfect transparency for any application you would like > >> to. > > > > Not exactly. Last time I tried, a compositing manager makes transparent > > everything including writings, and performs true transparency. It is > > significantly less comfortable than pseudo-transparency done by terminals > > themselves. A comfortable translucent set up requires a accurate settings in > > order to balance correctly eye-candy and easy reading. > > I know that many enjoy so much the mental-masturbatory process of > configuring and "tuning" their desktops to death, but some of us > managed to outgrow our pre-adolescent vices and actually use computers > to get work done, hell, or even to have *actual* fun like watching > films or perhaps playing games, instead of spending a lifetime > pretending that the look of our work area is some kind of third rate > kitsch 'art work'. > > Peace > > uriel > -- Atentament. Jordi Mariné
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 9:57 AM, Jordi Marine wrote: > you are a compulsive replier, you haven't time to use a computer Very well-known dicease: http://imgs.xkcd.com/comics/duty_calls.png -- « I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tanhauser gate. All those moments will be lost in time like tears in rain. Time to die. »
Re: [dev] [dwm] patch - nametag
On Thu, 29 Oct 2009 12:11:55 -0700 Evan Gates wrote: > This patch allows you to change the names of dwm's tags while it's > running. I find it's useful to change one of my 'misc' tags to a more > descriptive name if I find myself working on something specific for a > few hours. I like this. It made me switch from wmii to dwm. At least for today. -- Thomas Dahms
Re: [dev] [st] goals / non-goals for st?
This thread is about the features st should implement and transparency surely is a thing that shouldn't be implemented by st, so we should probably abandon this topic. I totally agree that transparency shouldn't be part of the features of st, althought I do use transparent. I thought that a point of view more elaborate than "transparency is for idiots" and such could be of some interest.
[dev] [surf] surf-0.3 released
surf-0.3 is out. There are still some bugs left, but I think it's time to roll out a new release because there changed a plenty of things: - changed cookiefile to cookies.txt - removed urlbar and searchbar using XProps instead - downloads are working - zooms website out, if the window is small enough - fixing surf to make it work with tabbed more smoothly. Mercurial * http://hg.suckless.org/surf Tarball: * http://dl.suckless.org/surf/surf-0.3.tar.gz please be patient as there are still some bugs, but feel free to give feedback. regards, Enno
[dev] [tabbed] tabbed-0.2
A new tabbed release is out: - fixing move() arguments in config.def.h - close tabs with middle mousebutton - cycle tabs with mousewheel - some speedup when resizing a window with many tabs - solving focus problems with surf - works now with xterm too - solving problems with windowmanagers which unmap windows Mercurial: http://hg.suckless.org/tabbed Tarball: http://dl.suckless.org/tools/tabbed-0.2.tar.gz Please report any problems you have with tabbed. regards Enno
Re: [dev] [st] goals / non-goals for st?
Do yourself a favour: stop calling others idiots. No. Great, yet another Uriel.
Re: [dev] [st] goals / non-goals for st?
And yet another idiot. Have fun... On Fri, Oct 30, 2009 at 2:28 PM, frederic wrote: >>> Do yourself a favour: stop calling others idiots. >> >> No. >> > > Great, yet another Uriel. > >
Re: [dev] [st] goals / non-goals for st?
It would be nice to see a features thread that didn't degenerate into a competition of who's the biggest cock. While I can understand why transparency is a bad idea, people have the freedom to want whatever they want. If the maintainers of the software don't want a particular feature in vanilla, and a person requests a particular feature, all the devs need to do is state that that feature will not appear in the vanilla source. The great thing about suckless software is that it's so easy to hack, it's simple and unencumbered and that's how it should stay. If people want to branch off or create a patch to extend the software with features they desire that's their prerogative, that's the beauty of suckless software. If I want the features of the software I use dictated to me I'd stick with Windows, if I wanted how I use the software dictated to me I'd stick with the GPL. I think freedom is an essential goal of suckless software, as is an open discussion of ideas. People shouldn't be berated for simply discussing a feature. If you disagree with something that's fine, but why degenerate into personal attacks? Now, in keeping with the original theme of the thread: A feature I wouldn't mind seeing in st would be the ability to spawn st as a direct endpoint to a pipe (not sure if that's already possible?). This would allow st to be used as a quick popup to display information, or as part of a multi-terminal application like an irc client, without needing to spawn an extra shell or consume an extra pty. 2009/10/30 hiro <23h...@googlemail.com>: > And yet another idiot. Have fun... > > On Fri, Oct 30, 2009 at 2:28 PM, frederic wrote: Do yourself a favour: stop calling others idiots. >>> >>> No. >>> >> >> Great, yet another Uriel. >> >> > >
Re: [dev] [st] goals / non-goals for st?
Take your hippy shit somewhere else. Retarded ideas will be met with hostility here. Aled Gest wrote: It would be nice to see a features thread that didn't degenerate into a competition of who's the biggest cock. While I can understand why transparency is a bad idea, people have the freedom to want whatever they want. If the maintainers of the software don't want a particular feature in vanilla, and a person requests a particular feature, all the devs need to do is state that that feature will not appear in the vanilla source. The great thing about suckless software is that it's so easy to hack, it's simple and unencumbered and that's how it should stay. If people want to branch off or create a patch to extend the software with features they desire that's their prerogative, that's the beauty of suckless software. If I want the features of the software I use dictated to me I'd stick with Windows, if I wanted how I use the software dictated to me I'd stick with the GPL. I think freedom is an essential goal of suckless software, as is an open discussion of ideas. People shouldn't be berated for simply discussing a feature. If you disagree with something that's fine, but why degenerate into personal attacks? Now, in keeping with the original theme of the thread: A feature I wouldn't mind seeing in st would be the ability to spawn st as a direct endpoint to a pipe (not sure if that's already possible?). This would allow st to be used as a quick popup to display information, or as part of a multi-terminal application like an irc client, without needing to spawn an extra shell or consume an extra pty. 2009/10/30 hiro <23h...@googlemail.com>: And yet another idiot. Have fun... On Fri, Oct 30, 2009 at 2:28 PM, frederic wrote: Do yourself a favour: stop calling others idiots. No. Great, yet another Uriel.
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 3:42 PM, Aled Gest wrote: > People shouldn't be berated for simply discussing a feature. People who support dumb things run the risk of mockery. I'd rather get burned for suggesting something stupid than have this list turn into a politically-correct hugbox support forum for the criminally inept. If you don't like it, go hang out on another mailing list. I'll mention here that I've altered some of my own opinions after reading arguments on this list. The vehemence with which a person defends a specific concept shows me how seriously they take that concept. Similarly, the amount of whining done by someone re ad-hominem attacks shows me that their priorities lie more toward "internet community building" than "discussing things," so I know they don't have a whole lot to say, on average. To wit: > A feature I wouldn't mind seeing in st would be the ability to spawn > st as a direct endpoint to a pipe (not sure if that's already > possible?). This would allow st to be used as a quick popup to display > information, or as part of a multi-terminal application like an irc > client, without needing to spawn an extra shell or consume an extra > pty. You want your terminal emulator to replace xmessage? Really? -- # Kurt H Maier
Re: [dev] [st] goals / non-goals for st?
> People who support dumb things run the risk of mockery. I'd rather > get burned for suggesting something stupid than have this list turn > into a politically-correct hugbox support forum for the criminally > inept. If you don't like it, go hang out on another mailing list. Well if you really want me to make a point about how people who are needlessly belligerent on inappropriate threads are evidently incompetent at life, that's fine. I could have a field day nitpicking the psychology of people who overcompensate for their own inferiority by directing disproportionate aggression towards hapless randoms who dare to suggest naive ideas. I just think development threads are more productive when socially inept morons aren't derailing conversations with fruitless personal attacks. You understand the inherent pitfalls of fallacious behavior right? > You want your terminal emulator to replace xmessage? Really? No, I want a terminal emulator that can behave like a terminal emulator. Last time I checked xmessage wasn't a terminal emulator.
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 04:01:43PM -0500, Kurt H Maier wrote: > You want your terminal emulator to replace xmessage? Really? xmessage can read from pipes? I like the idea of adding this feature to st... but maybe it should be done by adding a patch to st. Best Regards Moritz
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 4:32 PM, Aled Gest wrote: > Well if you really want me to make a point about how people who are > needlessly belligerent on inappropriate threads are evidently > incompetent at life, that's fine. I could have a field day nitpicking > the psychology of people who overcompensate for their own inferiority > by directing disproportionate aggression towards hapless randoms who > dare to suggest naive ideas. I just think development threads are more > productive when socially inept morons aren't derailing conversations > with fruitless personal attacks. You understand the inherent pitfalls > of fallacious behavior right? I'm sure you could have a ton of field days, describing for hours all kinds of irrelevant crap. Maybe you can read a book about adapting to different standards within different social groups instead of lecturing to people who don't care. It's a mailing list. Calling people stupid is not 'disproportionate aggression,' it's just calling stupid people stupid. Sorry if your life has caused you to consider honesty 'aggressive.' > No, I want a terminal emulator that can behave like a terminal > emulator. Last time I checked xmessage wasn't a terminal emulator. Which extant terminal emulators behave the way your proposed functionality describes? -- # Kurt H Maier
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 4:34 PM, Moritz Wilhelmy wrote: > xmessage can read from pipes? Yes. -- # Kurt H Maier
Re: [dev] [st] goals / non-goals for st?
> I'm sure you could have a ton of field days, describing for hours all > kinds of irrelevant crap. Maybe you can read a book about adapting to > different standards within different social groups instead of > lecturing to people who don't care. It's a mailing list. Calling > people stupid is not 'disproportionate aggression,' it's just calling > stupid people stupid. Sorry if your life has caused you to consider > honesty 'aggressive.' Perhaps in your eagerness to overreact you missed the point I was making, so I'll simplify it for you: Filling development threads with "you're an idiot" ... "no you" detracts from the thread's ability to develop. > Which extant terminal emulators behave the way your proposed > functionality describes? In terms of using pipes to communicate with other programs, all of them. In terms of doing so without consuming a PTY or spawning a child process, none that I know of. Are you suggesting that we shouldn't develop new software because no existing software does what we want? I've seen no strict definition specifying how a terminal emulator must communicate with other processes. Whether it acts like a host process spawning a child and communicating through a PTY, or gets spawned as a child process itself reading and writing directly through pipes, it's still a terminal emulator.
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 5:34 PM, Aled Gest wrote: > In terms of doing so without consuming a PTY or spawning a child > process, none that I know of. > > Are you suggesting that we shouldn't develop new software because no > existing software does what we want? I've seen no strict definition > specifying how a terminal emulator must communicate with other > processes. Whether it acts like a host process spawning a child and > communicating through a PTY, or gets spawned as a child process itself > reading and writing directly through pipes, it's still a terminal > emulator. I'm suggesting that if you want two clearly distinct jobs done, and they share a lot of similar code, you extract the duplicate code into a library and then write two applications against that library. In this case, we should wind up with st, which consumes PTYs and emulates a terminal, and we should wind up with your thing, which still sounds closer to dzen than a term app. Loading up application code with disparate functionality isn't any good. -- # Kurt H Maier
Re: [dev] [st] goals / non-goals for st?
Moritz Wilhelmy wrote: On Fri, Oct 30, 2009 at 04:01:43PM -0500, Kurt H Maier wrote: xmessage can read from pipes? make xmessage read from stdin with the "-file -" option, e.g. echo "mmh" | xmessage -file - regards, Nicolai
Re: [dev] [st] goals / non-goals for st?
> I'm suggesting that if you want two clearly distinct jobs done, and > they share a lot of similar code, you extract the duplicate code into > a library and then write two applications against that library. No you weren't. > In this case, we should wind up with st, which consumes PTYs and emulates > a terminal, and we should wind up with your thing, which still sounds > closer to dzen than a term app. > > Loading up application code with disparate functionality isn't any good. I've got no problem with the terminal part of st being modularized and being called from a separate stub that handles how it connects to other processes. The particular method I was thinking of to implement the functionality I want would actually reduce the code complexity of st by removing the code to allocate PTYs and spawn a child process. If you removed the spawning code from st, to implement an xterm like terminal you could have a separate program that allocates a PTY with itself on the controlling end, and spawns st attached to the other end, and then execs itself to a shell which inherits the controlling end of the PTY. That way you've effectively got something that does the same job, but you've removed complexity from st itself, and you've increased flexibility.
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 6:05 PM, Aled Gest wrote: > No you weren't. My clarification of my position was exactly as connected to previous statements as your accusation of the garbage you were spouting about no new functionality or whatever. Incidentally, this thread now stands as a counterexample to your hypothesis regarding the inability of petty argument to coexist with useful development discussion. Thanks for your help in this matter. > I've got no problem with the terminal part of st being modularized and > being called from a separate stub that handles how it connects to > other processes. That would be necessary anyway if the 'st daemon' idea were to be implemented. > That way you've effectively got something that does > the same job, but you've removed complexity from st itself, and you've > increased flexibility. More importantly, it allows the attachment of st frontends other than xlib-based ones to the controlling process, meaning that there can be directfb or console-based frontends, among other things. -- # Kurt H Maier
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 06:13:11PM -0500, Kurt H Maier wrote: > More importantly, it allows the attachment of st frontends other than > xlib-based ones to the controlling process, meaning that there can be > directfb or console-based frontends, among other things. Sounds like st will be a great project once it is working I like the idea of splitting the pty part from core. Regards
Re: [dev] [st] goals / non-goals for st?
> My clarification of my position was exactly as connected to previous > statements as your accusation of the garbage you were spouting about > no new functionality or whatever. Incidentally, this thread now > stands as a counterexample to your hypothesis regarding the inability > of petty argument to coexist with useful development discussion. > Thanks for your help in this matter. Don't kid your self. The most recent suggestion you made had no correlation to anything you said or implied in previous posts pertaining to our debate. >> I've got no problem with the terminal part of st being modularized and >> being called from a separate stub that handles how it connects to >> other processes. > > That would be necessary anyway if the 'st daemon' idea were to be implemented. > >> That way you've effectively got something that does >> the same job, but you've removed complexity from st itself, and you've >> increased flexibility. > > More importantly, it allows the attachment of st frontends other than > xlib-based ones to the controlling process, meaning that there can be > directfb or console-based frontends, among other things. Exactly, improved flexibility / modularity that reduces code complexity is win win in my book.
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 08:42:19PM +, Aled Gest wrote: > It would be nice to see a features thread that didn't degenerate into > a competition of who's the biggest cock. Thank you for this post. If I look at the rest of this discussion it really makes me wonder why I'm still subscribed to this mailing list.
Re: [dev] [st] goals / non-goals for st?
On Oct 30, 2009, at 19:51, Nils wrote: On Fri, Oct 30, 2009 at 08:42:19PM +, Aled Gest wrote: It would be nice to see a features thread that didn't degenerate into a competition of who's the biggest cock. Thank you for this post. If I look at the rest of this discussion it really makes me wonder why I'm still subscribed to this mailing list. Because it's hilarious! Especially when Lamb Sandwich starts whining.
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 10:01 PM, Kurt H Maier wrote: >> A feature I wouldn't mind seeing in st would be the ability to spawn >> st as a direct endpoint to a pipe (not sure if that's already >> possible?). This would allow st to be used as a quick popup to display >> information, or as part of a multi-terminal application like an irc >> client, without needing to spawn an extra shell or consume an extra >> pty. > > You want your terminal emulator to replace xmessage? Really? Actually I think this a good idea, xmessage is awful, and the job of a sane terminal is to display text, so a sane terminal should be able to simply and elegantly replace xmessage. (In Plan 9 rio windows are used to display text for example during the installer, a cool thing is that you can actually dynamically update the text in another window from a script.) uriel
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 10:32 PM, Aled Gest wrote: >> People who support dumb things run the risk of mockery. I'd rather >> get burned for suggesting something stupid than have this list turn >> into a politically-correct hugbox support forum for the criminally >> inept. If you don't like it, go hang out on another mailing list. > > Well if you really want me to make a point about how people who are > needlessly belligerent on inappropriate threads are evidently > incompetent at life, that's fine. I could have a field day nitpicking > the psychology of people who overcompensate for their own inferiority > by directing disproportionate aggression towards hapless randoms who > dare to suggest naive ideas. I just think development threads are more > productive when socially inept morons aren't derailing conversations > with fruitless personal attacks. You understand the inherent pitfalls > of fallacious behavior right? You are learning well... the dark side of the force is strong with you. (Ok, I suck at quoting Star Wars, whatever, it is a retarded film anyway ;P) >> You want your terminal emulator to replace xmessage? Really? > > No, I want a terminal emulator that can behave like a terminal > emulator. Last time I checked xmessage wasn't a terminal emulator. Then buy yourself a typewriter. uriel
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 11:03 PM, Kurt H Maier wrote: > On Fri, Oct 30, 2009 at 4:32 PM, Aled Gest wrote: >> Well if you really want me to make a point about how people who are >> needlessly belligerent on inappropriate threads are evidently >> incompetent at life, that's fine. I could have a field day nitpicking >> the psychology of people who overcompensate for their own inferiority >> by directing disproportionate aggression towards hapless randoms who >> dare to suggest naive ideas. I just think development threads are more >> productive when socially inept morons aren't derailing conversations >> with fruitless personal attacks. You understand the inherent pitfalls >> of fallacious behavior right? > > I'm sure you could have a ton of field days, describing for hours all > kinds of irrelevant crap. Maybe you can read a book about adapting to > different standards within different social groups instead of > lecturing to people who don't care. It's a mailing list. Calling > people stupid is not 'disproportionate aggression,' it's just calling > stupid people stupid. Sorry if your life has caused you to consider > honesty 'aggressive.' I disagree, there *is* "disproportionate aggression" in this list, I at least try to be disproportionately "aggressive". There is nothing wrong with this, it is exercising the most fundamental human right: free speech. As for its purpose, I agree that in some cases it is probably counter-productive, but that is for the "aggressive" person to worry about, and I still think that in some cases it can be a useful rhetorical technique to bring attention to something that might pass unnoticed otherwise. tl;dr: Being an asshole can be a good way to make a point. (Not to say that I'm good at it, but I'm trying to improve my asshole-skills.) >> No, I want a terminal emulator that can behave like a terminal >> emulator. Last time I checked xmessage wasn't a terminal emulator. > > Which extant terminal emulators behave the way your proposed > functionality describes? I have no clue, but you wanted to use a program that behaves like existing programs, why don't you use the existing programs? Reading from stdin is a basic and fundamental Unix design, and should be applied where it makes sense, I think it makes quite a bit of sense here. uriel
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 11:34 PM, Aled Gest wrote: >> I'm sure you could have a ton of field days, describing for hours all >> kinds of irrelevant crap. Maybe you can read a book about adapting to >> different standards within different social groups instead of >> lecturing to people who don't care. It's a mailing list. Calling >> people stupid is not 'disproportionate aggression,' it's just calling >> stupid people stupid. Sorry if your life has caused you to consider >> honesty 'aggressive.' > > Perhaps in your eagerness to overreact you missed the point I was > making, so I'll simplify it for you: > > Filling development threads with "you're an idiot" ... "no you" > detracts from the thread's ability to develop. This might be true, but also sometimes the only proper way to react to a stupid idea is to point out that it is stupid. >> Which extant terminal emulators behave the way your proposed >> functionality describes? > > In terms of using pipes to communicate with other programs, all of > them. In terms of doing so without consuming a PTY or spawning a child > process, none that I know of. > > Are you suggesting that we shouldn't develop new software because no > existing software does what we want? I've seen no strict definition > specifying how a terminal emulator must communicate with other > processes. Whether it acts like a host process spawning a child and > communicating through a PTY, or gets spawned as a child process itself > reading and writing directly through pipes, it's still a terminal > emulator. That the concept of 'pty' still exists in the year 2009 is quite fucking amazing. I'm surprised we don't carry punchcards around anymore. uriel
Re: [dev] [st] goals / non-goals for st?
On Sat, Oct 31, 2009 at 12:51 AM, Nils wrote: > On Fri, Oct 30, 2009 at 08:42:19PM +, Aled Gest wrote: >> It would be nice to see a features thread that didn't degenerate into >> a competition of who's the biggest cock. > > Thank you for this post. > > If I look at the rest of this discussion it really makes me wonder why > I'm still subscribed to this mailing list. There is no law that requires you to read every post sent to a maling list. Also, I'm sure no matter how retarded your mail client is, it has a delete function. uriel
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 09:06:29PM -0400, Andrew Antle wrote: > Because it's hilarious! Especially when Lamb Sandwich starts whining. It's nothing but arrogant, unfriendly and wannabe-elitist to talk like this on a public mailing list. And I'm not even going to respond to Uriels mails.
Re: [dev] [st] goals / non-goals for st?
On 31/10/2009, Nils wrote: > On Fri, Oct 30, 2009 at 09:06:29PM -0400, Andrew Antle wrote: >> Because it's hilarious! Especially when Lamb Sandwich starts whining. > > It's nothing but arrogant, unfriendly and wannabe-elitist to talk like > this on a public mailing list. But totally hilarious. Most people don't like being told they are wrong, so challenging people to defend their ideas means they'll put more work in to making you understand their idea to try to make you change your mind. The more aggressive your challenge, the effort they'll put in to defence. It's a good way to discuss things with random people and this mailing list does it really well. -- = http://jessta.id.au
Re: [dev] [st] goals / non-goals for st?
On Fri, Oct 30, 2009 at 10:10 PM, Jessta wrote: > On 31/10/2009, Nils wrote: >> On Fri, Oct 30, 2009 at 09:06:29PM -0400, Andrew Antle wrote: >>> Because it's hilarious! Especially when Lamb Sandwich starts whining. >> >> It's nothing but arrogant, unfriendly and wannabe-elitist to talk like >> this on a public mailing list. > > But totally hilarious. > Most people don't like being told they are wrong, so challenging > people to defend their ideas means they'll put more work in to making > you understand their idea to try to make you change your mind. > The more aggressive your challenge, the effort they'll put in to defence. > It's a good way to discuss things with random people and this mailing > list does it really well. > Some of the most morbidly fascinating highlights from this mailing list: 1) some people respond enthusiastically and with great vitriol to innocent-yet-ignorant comments, 2) they relentlessly pursue an "ignorant" poster with pointless berating as if they'll convince anyone of anything, 3) they defend this behavior as if it's actually helpful, and 4) they have little to no concern for the wasted time of the people who have to sift through their garbage to get to anything relevant or helpful. Yes, Uriel: we all have delete functionality. However, it's not the responsibility of subscribers to waste their time deleting non-dev-related emails. Just stop sending them. It is my humble opinion that the [dev] mailing list contributors just stick to [dev]-related topics. Please stop responding to emails as if this is Reddit. Yes, we know--you've got something snarky to say, someone hurt your feelings, you know things about stuff and feel compelled to share, and everyone should conform to the way you think about the world. But no one cares. So don't even bother sending that email unless it's about development. I subscribed so I could learn something about software development, not about how badly some of you communicate.
