There's some nice examples of something I've noticed - where you have a very clear issue and people pick away at stuff that's orthogonal to the issue and won't resolve anything. The question is clear, "gimme gimme gimme" is printed to stderr, it's not expected and we'd like to know why ... but there's comments like:
- "Why does your test script call man where it should fail?"
- "why do you need to do a 'man -w' every minutes?"
I get that there's a bit of mistrust in some things users report so in some cases we as developers need to be careful to establish the user's actual intent or whether they're describing their issue correctly. But this isn't one of those cases.
I get why people ask questions like that. Many questions on SO are often weird because of the XY problem [0]. Someone asks for X, people answering think doing X is really weird and difficult, and thus dig a bit more. They then find that the asker really wants to achieve Y which is simple to do.
That may be true but it often ruins StackOverflow as a repository of answers. There’s nothing worse than actually needing to do X only to find a StackOverflow page where 10 different answers give 10 different Ys.
Or when X needs to be done but instead all the comments hector the question with useless criticism.
If a subject matter expert thinks that people asking for X are falling victim to the XY problem, then I want to hear about it before I go down the mistaken road of implementing X.
If there truly is a circumstance which makes X the right solution, then that might warrant a new question being posted with the additional context to make that so. But I suspect it's much more often the case that the asker is simply being stubborn and doesn't want to change their plans.
You’re correct that they often aren’t, but all the same I find it amusing to read this comment attached to a StackOverflow link where the exact person who suggested “gimme gimme gimme” and the implementer both answered.
Obviously not the ones making the “why are you $X” comments in this case though.
Remember the name of the site that SO replaced, "Experts Exchange".
Obviously it's possible for non-experts to post authoritative-sounding answers on questions that they don't really understand, but I think that is a different category of problem from the "XY-problem" style answers.
Yes, I could agree with you there. I'm not going to defend the stickler moderators on there (just look how they shut down the interesting comments on the top answer).
There are places to ask the question "I think I need X. Is there a better solution?"
But the answer to the question "How to do X?" really shouldn't include more than a passing reference to "Here's how to do Y." If X is impossible, then that is of course the answer.
And as others have indicated, the most frustrating scenario that happens over and over is that once the "How to do X" question is asked, you can never get an answer to that question if the original poster relents and agrees that what they really need is an answer to "how to do Y?".
Imagine the question is something like "How do I concatenate these strings into an SQL query?"
Would you be willing to be responsible for the fallout of answering that question any other way besides "use parameterized queries instead"? Do you really think that should only be mentioned as a passing reference?
Absolutely, yes. Someone has to write the parameterization libraries. That is, whatever abstraction layer you want to employ, in the end SQL queries are strings.
And the passing reference to the potential misuse here can be a big bold statement at the top of your answer.
Except that you sometimes have to anyway (not for parameters, but to have dynamic conditions, filters etc.)
And since every question about such things get auto corrected to use parameters (which doesn't help, since it's something else entirely), You have millions of buggy self glued sql queries allover code bases. (but hey most of them are using parameters, so yay - progress)
In those cases the best solution would be to use a query builder library like JOOQ, I still wouldn't be willing to recommend someone in that position builds the query by concatenating strings together
Yeah, unfortunately, these days SO is relatively good for shallow questions but mostly terrible for niche questions when you're already at an advanced level on the topic. Often enough you get several inquiries about your use case from people at or maybe even below your level who can't really answer the niche question, you waste time explaining irrelevant details and fending off skepticism, and end up leaving without an answer.
I still occasionally post these _when they aren't urgent_ because there's an off chance someone will know, and a greater chance some future traveller will find it by search and turn up with a good thought or answer.
It's also encouraged to answer your own questions. So if you struggle with something, and find a solution, you can post the Q and answer at the same time even. To make it easier for others in the future.
You say it ruins it, but my in my opinion, that's exactly what makes SO valuable. Often, it's not just the asker of the question that's trying to solve X but asks how to solve Y. So when you search on how to solve Y, you might also find out a better way to solve X that doesn't involve solving Y.
And if you are really trying to solve Y, it's not hard to specify that in your question (I know I can solve X without solving Y, but I don't want to solve X, I want is to solve Y in this case). I wouldn't say "there's nothing worse" than that; it's a minor inconvenience.
I agree. If I'm sure my problem is not an XY problem, but I think it may well not look like that because it's such a weird situation, I will add all the context that explains how I got there.
Then either: I do know what I'm doing, and my explanation satisfies people, and they try to work on Y, or: it turns out I was indeed wrong, and I should have solved X some other way.
Either way it's a win for me (if anyone bothers to answer the question).
But it can be hard for either new people, or people who don't know the domain well enough to even know that it could be an XY problem.
The XY problem applies when someone asks how to accomplish something. In this case they want to know why something happens; what they’re doing around it is irrelevant.
It’s analogous to asking “why does pizza taste metallic to me?” and getting “why are you eating pizza?” as a reply.
Isn't the better analogy that, "If I take aspirin with water for a hangover it works but if I take it with whiskey it makes the hangover worse. Why doesn't aspirin work with whiskey?"
I would definitely ask them why they think they need to take aspirin with whiskey for their hangover.
No, it's more like, "Why do people literally float a few inches off the ground when they lick an aspirin then take a sip of whiskey?"
If that input indeed did cause that result, you'd expect a forum of human beings to have responses like this:
"Holy shit that result was most surprising! I have to re-evaluate my entire life now. Just curious, though-- what made you decide to lick aspirin and sip whiskey?"
Any response that didn't explicitly confirm the result would be signalling to the world that they are either a troll or a boring contrarian.
Similarly, `man` isn't ever supposed to output `gimme gimme gimme` as reported. That is surprising behavior. And that surprising behavior is trivially reproducible by the likely harmless act of setting your machine to the time specified and running it.
Thus, the fact that this reported case was actually a feature of `man` outs all the people who posted non-sequiturs as low-effort cranks. (Low-effort because they didn't even take the time to run a trivial test.)
Edit: just to be completist about it-- I suppose a respondent in either case could simply challenge the veracity of the report. But that's not what we're talking about here AFAICT.
Edit: to make a steelman argument here-- maybe not cranks, but people who have, for whatever reason, fallen prey to the act of low-effort crankiness.
And yet I think the probing XY questions are still important.
The answer could have been simply: "It's an easter egg. It's from an Abba song." Done. End of discussion, it answered the question.
But by probing how the user wanted the thing to work, and why it was breaking his tests, and that it was actually happening when he used `man -w`, the maintainer actually understood that it was not a harmless easter egg, and fixed it so it didn't happen when called with -w.
Despite the wording of the question I think it's pretty clear the real intention is to get their tests working. And even then, the top answers do in fact directly answer the question as asked.
Calling man in a test and expecting the output to match some particular value is a much weirder thing to do with man than eating pizza in the morning.
It is honestly a lot more likely that the reason man is outputting ‘gimme gimme gimme’ at a particular time of day is something to do with your crazy test setup than that it is a feature of man.
So for the pizza analogy, think of it more as ‘pizza sometimes tastes metallic to me when I cook it under the hood of my car’. The car situation seems likely to be relevant. It would be surprising, when someone asks a question like that, to discover that it’s actually because the frozen pizzas they buy when they drive to the parking lot where they then cook them under their car hood actually contain iron filings that were put there deliberately by the manufacturer.
The analogy is completely fine. "Why does the pineapple on my pizza taste metallic"? "You shouldn't put pineapple on your pizza" if the original bothers you.
It doesn't, though. As I see why asking "why are you eating pizza is wrong", but not why asking "why are you using man in your tests" is wrong. So your analogy is more of a misrepresentation of the situation than anything else.
If you don't want focus on the details, then don't provide them. If you provide them, it has to be because you think they might be relevant. And then it's relevant for people to ask for further details.
> As I see why asking "why are you eating pizza is wrong", but not why asking "why are you using man in your tests" is wrong. So your analogy is more of a misrepresentation of the situation than anything else.
So far you seem to be the only one failing to grasp the original point. Your misunderstanding of the analogy does not transform it into a misrepresentation.
This due to the use of "why" and "because" in English to introduce explanations that are fundamentally different and grammatically differentiated in other languages. One is a cause, as in the antecedent cause of a consequent effect, while the other is a purpose, the effect desired prior to undertaking an action. This is the difference between etiology and teleology, which many students fail to grasp. "Why does man print this?" asks for a cause, while "Why are you using man in a test?" asks for a purpose.
If someone only has a tangential knowledge of the problem, would it be better if they just don't give their input at all and simply leave the thread empty? Non-experts contributing their opinion doesn't take away space from the experts to answer it properly.
If the advice is really that bad or uninformed, then it should just be downvoted. That's not really related to the "XY problem".
On stack overflow, having several tangential non-answers will make the question look well-answered, potentially misdirecting the real expert away from it by creating a false impression.
I personally hate when that happens because usually I really want to do X for good reasons. In the end the people asking got help on troubleshooting their specific problem, but the question is still unanswered (or answered by “You don’t want to do that because you’re a beginner”).
If you are so unfamiliar with X that you require the advice of experts to implement it, then how can you say so confidently that the reasons to do X instead of Y are justified, even though those experts disagree?
If it's really true that the conventional wisdom about Y is just wrong, and X really is better in some cases, then it will be a long process to get all the experts to reconsider their assumptions, requiring battle-tested proof, and that probably won't happen in a single SO thread.
I'm not unfamiliar with the problem space and why I want to do X, I'm just looking on implementation details. If the question was "How should I solve that problem? Should I use X?", then sure "use Y instead because it's a better practice" would be a valid answer.
I'm the opposite. I often catch myself asking about Y and then needing to back up and ask about X. I even know the problem by name and can't help (occasionally) asking the wrong question.
I don't disagree, but then the question should be phrased that way, or it should be mentioned than there may be better way for generic use cases but the original question still answered.
I've been learning to recognize when I've been presented with a solution, rather than a need. Often times the solution answers the need, but lacks knowledge of either side effects, implementation time needed, holes in leaky abstractions, or something else that makes it less than ideal. Walking back to the need helps in proposing a better solution.
Yeah, I get that as well and sometimes feel the same. The difference is that a beginner tries to do Y, fails, think they can solve it by doing subtask X, so they ask X. But us with more experience know why Y didn't work and probably have a good reason for asking X.
But the answerers cannot know that. So adding a small snippet of what have been tried, or why X specific is what's needed is a good idea to steer the conversation in the correct direction.
I use SO all the time for gleaning information from the answers, but never for asking questions, for this very reason. The questions that show up in search results are full of great answers and information, but mine ended up full of people who didn't know the answer to my question but were eager to tell me about something they did know. Then I'd put more and more effort into providing context and justifying the question, until eventually the answers dried up. I decided I was better off seeking help on mailing lists, issue trackers, chat rooms, etc.
Yeah honestly I feel like it has gotten a lot worse since I was using it actively maybe 8-10 years ago. It seems to have moved towards a lot of people playing the karma game, and trying to focus on every flaw rather than trying to answer the question and give help. Nowadays, I usually try to find a community or forum directly related to the specific subject I'm working on.
However, it's hard to tell if the quality has actually changed, or whether it's just more geared towards novice programmers and I'm just not asking the type of questions that get help on the platform anymore.
Then specify the context as part of your question: "I want X. I think alternative solutions like Y won't work because...". As it is with many things in life the more effort you invest in the question, the greater the returns :)
Although tbh I quite often want the opposite, so I add "Alternative solutions/workarounds welcome" or "I don't see how I can avoid doing X but maybe..."
> "I want X. I think alternative solutions like Y won't work because..."
Listing all of the things you don't want to do would not only take up more words and effort than the question about what you do want to do, but is hopeless. Somebody who doesn't know the answer to your question but still wants to comment will find something that you were unaware you didn't want to do.
It's better just to answer questions directly, and then when somebody uses that solution and it doesn't get them closer to the solution to their real problem, they'll ask a better question.
Sorry, but that doesn't make sense and sounds like a rationalization for being lazy with the question. You're worrying about a straw man instead of trying to help out people who do know how to deal with the actual problem you have.
And bad solutions can still "solve" problems with horrible trade-offs, so instead of searching again for a better solution people may just employ the worse one unaware of the better possibilities, consequences be damned.
I think it depends on the quality of the question.
For instance, if it's a semi-vague question just pointing in the direction of a solution, then I think it's fair to question the motivation of the poster.
But if it's a very precise question about how to accomplish something specific, I think the burden should be on the person answering to add the clause: "you can do X, but its generally not considered a good idea because Y".
Honestly if you can't answer the original question, I get the impression you're just trying to be a smarty-pants and show off some domain knowledge you have which is related to the task at hand.
The point is that SO is actually less about the person asking a question. That is only one person.
But people look for already asked questions by searching for them. And I don't think that there are many things that are more frustrating, then finding a questions that describes your problem X perfectly and it has only answers to Y.
Since SO exists for the readers and not just the asker, I think that makes it even more important to highlight all the reasons not to do X if it really is unlikely to be the best solution.
Maybe the asker really would be best suited with X due to some contrived circumstance, but is that true of everyone else who finds the thread too? Probably not.
I think it’s similar to how experienced users access consumer support processes. When you call a support line, you might know exactly what you want, and just want to be routed to the process you know you need, but 95% of customers are better served by being put through the “have you tried turning it off and on again” process.
Similarly on Stackoverflow, a majority of users probably are doing it wrong and are helped by the XY-troubleshooting approach.
Experienced users who really do want X end up being collateral damage.
Before applying an XY troubleshooting approach, one should learn to recognise XY problems. While some cases may be ambiguous, I’d argue this one isn’t.
Sometimes experienced users are also served well by walking through the steps. At least at our company, you see field technicians who think they know what is happening and try to short-circuit the troubleshooting process. Sometimes they are correct, but oftentimes they miss a significant detail that they would have caught if they had just followed the normal procedure.
Well, in this case I would also like to know, out of pure curiosity. I cannot come up with a viable reason on my own why you would run 'man -w' as part of a test.
Asking why to a part of code or workflow is a good thing, even only because of curiosity. After knowing it, you may find the reasoning brilliant, or ridiculous and dismiss it and that's it.
However if any chance you have the same situation as OP, it may come out valuable, either currently or in the future.
I would have asked the same question for the same reason. A sibling comment introduced me to a feature that I wasn't familiar with. And that's why I'll continue asking curious questions until the day I die.
Why would there be more to it? I wanted to ask the same question, just because I simply did not know the answer. In fact, I am curious how you became so wary about such a simple, uncomplicated and direct question.
It's a bit of a Stackoverflow trope, so much so that it shows up in these "parody questions" that surface from time to time.
In some cases the people answering have the experience and breadth of knowledge to understand the "real" question being asked, even if the OP doesn't quite have it yet. Other cases, it seems like arrogance and showboating, and doesn't contribute much where a simple direct answer would be best.
The one that gets me is seeing an answered question, with a bajillion upvotes, locked by mods as "off topic" or "not useful" or whatever. Clearly a relevant question with a useful answer, as evidenced by the many comments and kudos. Ugh.
People prefer problems they know the answer to. Sometimes, when they don't know the answer to a problem, they'll try to cram it into a shape they recognize so the answer they already have works.
I think that's much more the case than the whole "XY" issue. It's clear the people asking "clarifying" questions about the workflow didn't have the slightest idea that man did that, much less why. But they can't get points or a feeling of accomplishment from recognizing that they're out of their depth and staying out of the discussion.
See also the questions that amount to "Why aren't you using the operating system/language/framework/library I'm actually familiar with, so I can answer you and get points?"
That is one of the things that turned me off of Linux in the very early days ... every time I tried to find out how to do something, I was a big moron for not using someone else's distro.
Thanks for articulating this. I call them XY inquisitors. We had a couple at work a few years ago and any question directed at them was met with a somewhat derisive "What are you trying to DO?".
Of course there are cases where the question poser of Y benefits from having their X identified, an archetypal case here:
No, not exactly. From [1], the XY problem is "you are trying to solve problem X, and you think solution Y would work, but instead of asking about X when you run into trouble, you ask about Y."
So person is trying to solve X, but asks
"How do you do Y?"
"Why are you trying to do Y?"
"Well, I want X and Y seems to be the solution"
"No, to solve X you want to do Z."
In this case the asker nicely gave their X as part of the question, but the bulk of the question was still about trying to move forward on their mistaken "solution" Y.
They are different problems. Stripping the final character from "3.14159" does not produce the same result as rounding to 3.1416.
The first action concerns a syntactic property of PI's decimal representation while the second action concerns a semantic property of PI's value.
A related example given on https://xyproblem.info is a user asking (Y) how to extract the final 3 characters of a filename string when he probably intends to ask (X) how to retrieve a filename's extension.
Agreed. IMO StackOverflow would be greatly improved if they implemented a rule barring these responses unless they first answer the actual question at hand.
To build off of another user's example, answering
>"If I eat pizza in the morning, why does it taste metallic?"
with
>"Because of a chemical reaction due to blah blah blah... which raises the question- why are you eating pizza for breakfast anyways? Avocado toast is superior for <reasons>"
Would be far more productive of a response for both cohorts of users; those searching for the direct answer and those searching for a better solution of what to have for breakfast.
> people pick away at stuff that's orthogonal to the issue and won't resolve anything.
Sometimes it’s a case of “I don’t know the answer to that, but I’d like to help. I’d like to know more about why you’re doing that so I can perhaps suggest something that doesn’t require doing that anymore.” Which indeed may be very helpful because even if you knew the real answer to your problem, in many cases you’ll need a workaround since the behavior probably won’t be fixed anytime soon.
I like to read the reasoning behind things that appear to be spurious because sometimes it turns out they have a good reason for doing it that I haven't considered, and it might be something I want to incorporate in my practices.
Reading all of the replies and context around the solutions, you're right that it doesn't appear to be one of those cases. But I don't think it was that clear cut from the original question.
The counter to this is, I believe, much much more common on SO: someone comes up with an odd solution to a problem in their head, tries to implement said solution, runs into challenges and comes to SO asking for help making their solution work. That then leads to over-engineered workarounds for hurdles they would not have encountered had they asked for help with their actual problem.
It can be useful. I remember asking about a problem I ran into in a convoluted solution and someone suggested I should try a much simpler solution which was actually a better idea.
It can be, if the people involved are knowledgeable. In this case and a distressing number of other cases, it's clear the people piping up have no idea what's going on (and some aren't even paying attention when reading the initial question). They're imitating what knowledgeable people do to feel like they're contributing.
I think it is something like the old joke where you tell the doctor that it hurts when you do something and the doctor says stop doing it. Often, we can eliminate the problem by factoring it out altogether. In this case people observed the problem to be solved as a failing test case. The author could have avoided being ask why by just stating the facts and not trying to explain why he observed it.
Sadly while many people enjoyed it, others were annoyed by it. And the author has now removed it.
I find it hard to relate with people who not only would be annoyed by something like this, but are annoyed about it enough to push their view on the internet to the point that the author feels the need to remove it.
In my view, the best response to those people? Update it to a more recent, or perhaps a more recognisable reference. Perhaps "Rocket Man".
The person asking the Q wasn't annoyed by it as far as I can tell (just understandably confused).
And the author's initial response was to leave the easter egg in, but to just fix the bug in it, since this behaviour was never intended (the intent was to trigger the easter egg on error condition, the bug was that it also triggered on manpath lookups).
Later in the thread the author mentions they eventually removed it completely after "some reflection", but they don't really expand on their reasons.
Were people annoyed? Was the author pressured? Was that the reason?
I'm the author. Wow, this is suggesting a lot more drama than actually happened. I just decided that the joke (which after all was not exactly the height of sophisticated comedy) had had its day. I'm sure I could have dug my heels in and made a big thing of it, maybe freewheeling open source developer versus humourless corporate internet, and I imagine I'd have had people lining up as defenders and detractors and whatever, but the thing is ... if I'd done that, it wouldn't have been funny any more anyway, so why bother?
For me, the point of an Easter egg in software is to make people who discover it smile without getting in their way: make a few people's days a little brighter. The nature of this one was that it wasn't all that likely that people would notice it - you had to run man without non-option arguments at the right time and you also had to know enough about ABBA for the output to remind you of the lyrics. For six years I heard barely a peep about it, and I'd pretty much forgotten about it myself, then suddenly it turns up on Stack Exchange and is all over the internet. Somebody on HN suggested that maybe this was the fewest bits needed to encode a widely-distributed earworm. The Register later had a comment thread on it full of ABBA puns. I'd only ruin it if I decided to be an arse about it; for a formerly-obscure silly bit of code, it isn't going to get any better than this anyway.
Four years later, it still occasionally crops up and I get an ABBA earworm for the next day. I'm not sad about that!
I can think of a reason why I would take it out: it’s an easter egg – i.e. unnecessary – that has already caused a problem once in a way that was not foreseen.
Of course there may be some that have been using the existing behavior as a convenient way of telling if it is 00:30, but they have so far apparently remained silent.
> Of course there may be some that have been using the existing behavior as a convenient way of telling if it is 00:30, but they have so far apparently remained silent.
I'm half curious and half afraid of this being an actual thing. Do I try it or not? I feel like doing this on a remote VM spun up just to do it would be wasted with no speakers. Do I spin up a VM on my local machine? Or screw it, where's the fun in no risk?
> Sadly while many people enjoyed it, others were annoyed by it. And the author has now removed it.
One could also do like the nano developers did and add a straight forward configure flag to disable Easter eggs, which some distros then dutifully set for their nano packages.
Humour, fun and games, and easter eggs are fine as long as they don't interfere with the actual functionality of an app or don't break other apps and workflows.
It isn't an Easter Egg, it is a defect with intent. Using a program at 0:30 isn't an unusual precondition and as seen here it will break stuff. Nondeterministic behaviour in a relatively common use case is bad. As seen here, predictably, it is breaking someone's test pipeline.
If they want a cute reference every invocation, fine. If they want a cute reference in a bizarre edge case, well maybe. Still poor taste. I don't like to think what it will take, but sooner or later the people demanding that programs do what they are documented to do are going win the battle. They have technical correctness on their side.
If we are going for technical correctness... Anything being broken by this is relying on the output of man with no arguments which is not documented as far as I can see, other than that it should have exit code 0.
Where is the boundary between responsible and harmless fun?
Perhaps I should be careful not to edit this comment in case someone's test pipeline curls it and checks the content.
To be clear, he original stack exchange post was calling “man -w” which does have defined behavior. The maintainer of man fixed it at that point to only happen with the bare “man”.
Presumably because the programmer likes that element of western culture. Are programmers supposed to conduct a poll among global stakeholders before they implement an easter egg?
This reminds me some review or article i read many years ago about OS/2 2.0 (the one before Warp) that wrote something along the lines of IBM tried to use a color palette that would be appropriate for all cultures around the world and ended up making a user interface with colors that looked very bland for everyone :-P
Oh come on, ABBA was probably the most global phenomenon ever coming out of Europe. Everybody is an ABBA fan, even if they haven't discovered it yet ;)
I’m in my late 30s and have never understood the Abba obsession. I’ve heard some of their music and it doesn’t really do it for me. And the weird way everyone acts about Abba, like you see in this thread, just reinforces that for me.
It's probably at least partly a 'you had to be there' situation to remember how popular, globally, that band was back in the 70's. The fact that they weren't from the US or UK made them stand out even more.
I like seeing reflections of creators’ personalities in code. It’s a little reminder to not take myself so seriously, to remember that these artificial systems called computers were totally created by humans and finally, that creativity in code is one of the human essences imbued in these systems.
I wonder if AI’s will create Easter eggs in their creations? Would they see them as a form of play, or only as a form of waste? What would that say about the eventual differences between a human and an artificial mind?
man is not a safety nor mission critical system. It was trivial to work around functional anomalies. There was nothing wrong with this, and it was hilarious.
I'm glad the VLC developers never backed down from the Santa hat popping up near Christmas, despite ridiculous criticism from a tiny minority of users.
I am surprised that they are serious when saying "even a single person being offended is one too many". Not want to start yet another flamewar on CoCs, but how is such a rule even practically enforced ?
Given it's impossible to respect for a project of this scale with this many users, it just feels like a fake statement for good PR
I feel like this makes the whole move even less respectful that if they'd have done nothing about the Santa hat complains
The maintainer of VLC is French. We have a culture of parody and making fun of everything.
This costs lives - people in France are killed because they made fun of the imaginary friend of some people. This is horrible and, unfortunately, we as a society start to give up. Teachers are told to be sensitive and not show pictures of gods, tomorrow this will be creationism and homeopathy and we will end up as another US.
I get offended all the time, but people are free to express their minds without fear. Even if they are obviously wrong because they do not agree with me (whom in contrast is always right and they do not get it).
Blackmail, master git branch, blacklists - all these changes are simply idiotic and the people who are proud of having changed that (and removing a hat on an IDE) probably do not realize that everyone officially tells them that we are proud of not offending them anymore, and when the micros are off they are called negros, twags and whatever word is painful to them. This is really sad.
They are the first ones to lose here, by having invisible walls built around.
I have a very good friend (a woman) who left a great company because she joined when the "diversity" program was live. She was told by her male colleagues that it used to be who you know, who you sleep with and now if you are a good match for diversity. She was brilliant but could not stand that and left for a smaller and more normal company.
All these forced ratio and PC is really against the ones it tries to help or make comfortable or not offend. And to be clear - having been on the receiver side of such campaigns (a minority), it took some time to build trust wit the ones who were not part of the minority. I also felt how it is to be a mnority as a kid - and it was horrible.
But PC is not the way to fix that.
I used somewhere else the analogy of catholics in France. They are being made fun of, they react (or not) but it ends here. This is the reason why they are integrated to French culture, and protected by this culture. The village I live in has a yearly mass outside of the church. As a complete atheist I find this great because this is a tradition and I like to see the folklore (whihc is faith for the ones who attend the mass). OTOH catholics do not try anymore to actively get in your bed to check what you do there, or try to push some god into our school books. And we like them.
I am offended that people didn't recognize that post as a joke. Or - alternatively - a ridiculous position that is tantamount to a joke.
Seriously, while on the one hand I welcome that we have become more culturally sensitive, on the other hand in some situations we should just get a thicker skin and learn again to say 'nope'.
Yea I remember when it went down, being a lifelong user of VLC I was pretty active there. It seemed obvious to me it was a joke, but so many were sure it was not.
Happened here the other day in a Perl thread. Someone made a pretty funny (to me) joke. Having used Perl too much I appreciated the joke but some read it differently.
Like the tabs v spaces, Vim or Emacs, to me it seems funny and nothing to get riled over but some just become so invested in taking offense/personal.
At what point does a software become mission critical? Would we be so accepting of this easter egg if it was in 'cat' or 'grep' rather than 'man'? I mean, yes, it's open source, so all downstream users can patch it out, but shouldn't unexpected output be considered a bug by the main upstream maintainer? How about an official branch, man-with-easter-eggs for users who want to debug this kind of fun at 00:30 in the morning.
Conversely why does your determination that an open source project is 'mission critical' to your use case obligate the author to make any changes at all for you?
I don't think the maintainer should be obligated to do anything. It would be courteous to treat it as a bug and maybe even provide a patch so that downstream users can easily fix it, but not an obligation. It looks like this one is already fixed so the point is moot.
If the primary maintainer of 'cat' decided it would be funny to have it output "meow" when run at 00:30 in the morning, it's totally their right to do it. I'd expect a lot of downstream users wouldn't find it that funny and would want to patch it out pretty quickly.
I don't think 'man' is that commonly used in scripts or as part of other automated processes that could go wrong. Most other unix utilities are fairly commonly used that way and a small behavioural change could be expected to break something somewhere just due to the sheer volume of use.
I'm not actually that surprised the easter egg broke something for someone even in 'man', for the exact same reason, but it's probably less expected than with grep and lots of other unix utilities.
I think it's mildly offensive to some because they view utility software as a tool that's meant to be invisible. You don't want your hammer singing Christmas carols even if it's harmless. It just feels out of place for this item that's supposed to have a single purpose which otherwise would do one thing and only that one thing. I understand the argument that it's fun, but I think the "it's fun" people are a little too quick to react when others say they don't want it. No one's trying to ruin your good time, it just feels weird. Sometimes I'd rather my tools be impressionless and predictable.
The original request was ridiculous but in fairness the "if you don't like it, fork it" attitude is really bad too. Forking something isn't zero cost. You'd have to maintain it, and then try to get developers to come to your fork, teach users about your fork, and then you end up with the annoying ffmpeg/libav situation where you have two similar but different projects.
It's kind of like saying "if you don't like Trump why don't you just leave?".
A better and more honest response would have been "I have considered your idea and I unfortunately disagree and won't implement it."
> After some reflection, I've removed this Easter egg. It'll be gone in the upcoming man-db 2.8.0.
Oh well, it was quite funny while it lasted. I like to imagine a person searching "man gimme gimme gimme after midnight" and being, for lack of a better word, rickrolled with that ABBA song.
I personally find it weird to treat any output in stderr as an error condition. It is very common in Unix world to use stderr not only for error messages but also general mundane runtime logs and progress indicator messages. Moreover, programs usually define what it should output to stdout, but not necessarily to stderr. After all, exit codes and `set -e` are a thing.
I understand it derails the point of the exchange, but I cannot fathom how this could be a legitimate use case. I'm not saying it's not, quite the opposite, I'm sure it was, but my curiosity has been piqued and for no reason whatsoever I must know.
It reminds me of the Married with Children episode where AL has a piece of a chorus of a song he remembered and it drove him insane until he remembered. It was hm hm himmmm and the song was I Will Follow Him, I believe.
I felt that, I had read a book as a child and it fascinated me and started my lifelong obsession with books. I could remember parts of the book, but search engines sucked for many years. I don't remember when but at some point google crawl bot scraped the synopsis of the book-it was a Forgotten Realms book 'The Night Parade'. Incidentally it was very little like I had remembered but I still loved re-reading it.
Anyway, hopefully that will happen with this question one day. I'll remember it, search it, and maybe find the answer.
On the contrary, printing the easter egg to stdout would have made it be recognized as part of the legitimate output. Here, "gimme gimme gimme" is not a valid manpath at all. This might have led to a even more subtle issue that is harder to debug, as the consumer tries to interpret gimme as a path to man pages.
Why? Stderr is meant to be a secondary "messy" output stream mainly for human consumption. The name is wrong. It should just be "output2". If the original poster on SO had correctly used stdout and ignored stderr, this would never have been a problem.
I thought about this recently, too, but it’s “correct” behavior.
Imagine you’re running curl. Do you want it’s progress in stdout when you’re piping it? No. You want the output, and you shouldn’t have to use —silent to get only that.
Gimme gimme gimme is the output. IMO the joke making it obviously different is better than the joke making it subtly different. Imagine how annoying it would be if it only had a 1 in 100 chance to happen, for instance.
The projecting going on is impressive. Where is that question "entitled"? How do you even know it's from a company, it's not like running CI is something only evil capitalists do, and what amount of open contributions said company does?
Okay, riddle me this: I work in a restaurant. I hand a bill to my customers. They leave without paying.
But actually, how do I know they haven't paid? Maybe they gave the restaurant money ahead of time when I wasn't around, or they paid secretly behind my back...
Or they just haven't paid their bill and i don't need to dig into it further. i ask them. If they paid, they'll let me know.
If they have, I'll know. If I don't know, they likely haven't. If they have anyway, they'll tell me.
When I go ask questions on Stack Overflow I don't usually go "btw I work for XYZ, we are maintainers of A/B/C and contribute to D/E/F/G/H", no, because it's not relevant. Even though the maintainers of Linux tools very likely use at least one of A-H.
You're completely missing the point of my post(s).
If you're contributing back to the software somehow, you'll have a more direct line to the developers. I've worked around, with and in open source nearly two decades, I've never seen this not be the case for anyone whose contributions weren't insignificant.
If your issue is anything but trivial, you'll be going through channels where it is in fact obvious you have contributed back. Not stack overflow. For this issue it absolutely applies.
If you can prove to me that the original poster/company has significantly contributed to the utility in question, I'll buy you a pizza. Your choice of toppings.
Okay, for the specific tool, sure. I tend to view this more as an ecosystem thing, and wouldn't consider someone who contributes elsewhere as someone scorn-worthy "not giving back" even if they haven't touched my specific small piece of software before. We started with
> God forbid you disturb the automatic tests of a company who's using your software without giving you anything in return.
By that measure the reaction to KDE CI asking about this man bug would be the same: "fuck them, what did they ever do for us". Fair?
This of course would be different for the (all-to-common) example of someone barging in and making threats/demands, but that's not the case here. Someone asked a question, nothing more.
I get what you mean and i agree to some extent. With that said i think the general disdain is justified given that the absolute majority of people and companies do not in fact contribute back.
Those who do shouldn't feel targeted by such statements imo.
Yes, I'm also very much talking about this specific case, where someone posted a factual question to a community channel. No demands, no "how dare you", no shouting, not even directly poking a maintainer. And I find the reactions jarring that just because they mentioned "our CI" suddenly they have to be bad guys. (Hoping that an end-user asking "my script unexpectedly failed" would not also get "what did users ever do for us" response)
I worked for a company where a developer put a dirty limerick in a UI control, activated by a keystone sequence.
They also turned on output tracing via another keystroke sequence.
During a presentation, one of the consultants needed to turn on tracing in front of a VERY large multinational client (heavens knows why, it was in front of C-suite execs…). They hit the wrong keystroke, and up popped the limerick - on a large projector, in front of the CEO.
I'm not saying putting easter eggs in is a good practice, only that it's not rare. I think with pretty much every company I've worked for, putting in easter eggs was specifically forbidden. And, in every company, they were put in anyway -- they just had to be sneaky enough to pass through code review undetected (which, I think, improved the quality of them!)
I don't think software is capable of wanting anything. As a FOSS user the less "seriousness" the better. Life is just more fun with jokes. I love that I can build "sudo" with an option to have it insult me when I get my password wrong. Who wants to live a serious life?
It's a criticism of the way FOSS software advocates seem to want to eat their cake and have it too. They ask the world why they aren't using more FOSS software, which has all these benefits from being free and open, and when the world replies with a list of all the downsides of relying on software written by people hacking in their spare time --see: JWZ and the CADT model-- the advocates fall back on the defense that you can't complain because it is free.
I know it sounds ridiculous, because free software is written by a diverse group of people with diverse goals, but this conversation happens all the time because its advocates often try to represent it as a cohesive whole, that it very much isn't, in pursuit of their own agenda.
- "Why does your test script call man where it should fail?"
- "why do you need to do a 'man -w' every minutes?"
I get that there's a bit of mistrust in some things users report so in some cases we as developers need to be careful to establish the user's actual intent or whether they're describing their issue correctly. But this isn't one of those cases.