Illusory Truth Effect - <AUTHOR> https://en.wikipedia.org/wiki/Illusory_truth_effect <comment><USER2> There's also [https://digest.bps.org.uk/2019/06/26/higher-intelligence- and...](https://digest.bps.org.uk/2019/06/26/higher-intelligence-and-an- analytical-thinking-style-offer-no-protection-against-the-illusory-truth- effect-our-tendency-to-believe-repeated-claims-are-more-likely-to-be-true/)

(via [https://news.ycombinator.com/item?id=20284218](https://news.ycombinator.com/item?id=20284218), but no comments there)

</comment><comment><USER3> Has this been affected by the on-going replication crisis?

[https://en.m.wikipedia.org/wiki/Replication_crisis](https://en.m.wikipedia.org/wiki/Replication_crisis)

<comment><USER4> I wonder about that too. But I've heard about the effect a lot so it must be true ;-)

</comment></comment><comment><USER5> Perhaps this can be rationalized from a Bayesian context. Unless your prior is that you're 100% sure of something (which no one is) and you don't completely ignore what other people say, your posterior will eventually shift to the opposite side.

<comment><USER6> I think the error made here could also be described in Bayesian context: your posterior shifts to the other side because you keep counting repeated instances of the same information as new evidence.

<comment><USER5> That would be an error if you know the repeated evidence has correlation 1. The studies try to make this clear to the participants, but it's plausible that after a week they forgot where they read some of the repeated facts and treat them instead as independent information. I'd be interested to see how the interval of repetition affects the results.

</comment></comment></comment><comment><USER7> "Sometimes people don't want to hear the truth because they don't want their illusions destroyed" \--Friedrich

<comment><USER8> 'Sometimes' seems to be a major understatement.

</comment></comment><comment><USER9> I'm kind-of surprised this didn't get studied earlier. This was one of the pillars of Nazi propaganda - or indeed, come to think of it, presumably any propaganda. Relentlessly repeat your lies, and eventually people believe them.

</comment><comment><USER10> I wonder how this can easily backfire. Eg if someone repeats something repeatedly you can learn to believe it, but if you ever prove it wrong you never trust them again.

</comment><comment><USER11> Reminds me of the Microsoft Halloween documents.

</comment><comment><USER12> Yeah, I've heard about it already, probably true. ;-)

Does it take a twisted mind to apply that pattern to [https://xkcd.com/552/](https://xkcd.com/552/) ?

<comment><AUTHOR> >Does it take a twisted mind to apply that pattern

Not necessarily. They say the best liar is one who doesn't know that he's lying. Take the state of news today, we have bloggers who parrot a source with no verification and often zero comprehension of what they are reposting.

RMS's issue a few weeks ago exemplified this effect with probably no single twisted mastermind. An under age girl was forced to ask a billionaire pedo for sex who turned her down was shortened to. Billionaire pedo forced an underage girl for sex. The shortened sensationalized version motivated by advert money then spread like wildfire.

See the link below for how word of mouth stories become distorted with transmission. [https://en.wikipedia.org/wiki/Rumor#1947_study](https://en.wikipedia.org/wiki/Rumor#1947_study)

</comment></comment><comment><USER13> If you like this area of study I recommend studying object relations and reification.

Object relations is all about how we strive for consistency in how we observe the world. It helps explain how people react and understand things.

Reificaction is also a really cool tool to bring in since when people go around repeating some thing.

Hm, like "gig economy". Like you're supposed to sit there and just accept this loaded concept, which some may believe implies accepting falsehoods, let me explain:

Gig Economy: As if, you're powerless to shape environment. No statute could be created to make employement / labor more fair and stable (let alone generous). You can't influence it, analyze it, criticize it, lobby, vote. Somehow there isn't enough wealth to give everyone a living wage. Don't even bother. Let's imply the systems to fix it don't already exist - even when they do - and it could be done by the end of the year, a few months?

Reification is amazing because it's all about injecting life into abstract concepts. It's where we create and give meaning to new words - it's what comes before illusory truth repetition.

And it's amazing how things shift. For instance, USA - one big thing that makes us famous is big, fat paychecks. But today if you read the news and hear people speak, it's as if there's an implicit acceptance it's okay to give corporations welfare and consistency by the way of our laws, but not reciprocate by giving it to the workers?

Then sometimes you read that having better employment conditions and wages are "socialist"? Lol? You could say: Nope, capitalism is all about huge pay checks. We're sharing this success we created as a private collective of workers. And you're very welcome!

(And by the way, you all pay taxes that shore up the system, you're welcome for that too, as you're strengthening the system and helping downtrodden people you don't even know, you amazing humanist you)

When someone says "Gig economy", go "Wait a second, who said it was okay to accept that, and why are you referring to gigs as employement?", then you can say, "I define employment as pensioned, salaried, position paid enough to comfortably support a family 4"

Perhaps one could repeat "living wage" about 3 times every time they here "gig economy". Why tolerate anything less than comfort, stability and dignity for us? As if we lack the moral collective conscience and intelligence to do it? Lol?

<comment><USER14> > If you like this area of study I recommend studying object relations and > reification.

> Object relations is all about how we strive for consistency in how we > observe the world. It helps explain how people react and understand things.

I am very interested in this sort of thing, are there any resources or names you can recommend looking into?

</comment></comment><comment><USER15> I have a friend who is a lawyer. He seems to believe that rhetoric and logic are the same thing. Links like this bring me bad memories.

<comment><USER16> A lawyer's job is not to actually find out the truth, like a scientist. A lawyer's conclusion will not be tested by a harsh reality with which you can experiment. A lawyer's job is entirely to _convince_ other people of things. If people are convinced, the job is done; there are no further repercussions if the truth turns out to differ.

Therefore, your lawyer friend likely has never thought about what logic is, or what a scientist does, and how physical reality with experiments is a harsh and unforgiving master, and therefore believes that everything is what he does – i.e. rhetoric.

<comment><USER17> There is also a distinction between logical and quantitative thinking. Some people operate mainly out of a "whether or not" mindset, and they are not inclined to think in terms of "how much", "to what degree", or "how likely". Scientists tend to be quantitative thinkers, although computer scientists are quite often logical thinkers.

<comment><USER18> Agree in principle, but I have an issue with your use of the terms "logical/quantitative". A pedantic nitpick to be sure, but the "logical" mindset you describe is one of the most prevalent logical fallacies, that of the "false dilemma" [0]. Maybe there are even better ways to describe it than as a logical fallacy, but calling it "logical thinking" leads down the wrong track IMO.

[0] [https://en.wikipedia.org/wiki/False_dilemma](https://en.wikipedia.org/wiki/False_dilemma)

<comment><USER19> He did not claim they were exclusive.

Your comment is an example of the fallacy fallacy.

<comment><USER15> The "fallacy fallacy" is valid for itself, though:

> since the fallacy fallacy is itself a fallacy, it cannot be used to label an > argument's conclusion as false without committing it in the process. "You > have used the fallacy fallacy, therefore you are wrong"

[https://rationalwiki.org/wiki/Fallacy_fallacy](https://rationalwiki.org/wiki/Fallacy_fallacy)

</comment></comment></comment></comment></comment></comment><comment><USER17> It's particularly effective when combined with "Big Lie".

[https://en.wikipedia.org/wiki/Big_lie](https://en.wikipedia.org/wiki/Big_lie)

<comment><USER20> I don't follow. The "Big Lie" is a conspiracy theory devised (or at least advocated) by Hitler in order to justify antisemitism. It's not a true phenomenon -- like the Illusory Truth Effect -- but something Hitler _falsely_ asserted the Jews did.

<comment><USER17> From the wiki reference: >"A big lie (German: große Lüge) is a propaganda technique and logical trick (fallacy)."

It is not a specific big lie, but a class of lies that exploit a certain mass naïveté.

<comment><USER20> > _" It is not a specific big lie, but a class of lies that exploit a certain > mass naïveté."_

At face value, yes. In practice the term is exclusively tied to Hitler's meaning, who coined the term. I'm not even sure if "Big Lie" has ever been used in another context, possibly because the term is a Nazi invention. To be clear, the "mass naïveté" of "The Big Lie" is (alleged by Hitler to be) the populace's, who "believed the Jews" when they claimed (always according to Hitler) that Germany's loss in WWI was to be blamed on Ludendorff. There is no other real-world usage of the term. And we know this Big Lie was itself a lie coined by Hitler, and this alleged conspiracy to exploit the mass naïveté of the people didn't actually exist.

From Wikipedia:

> _" The expression was coined by Adolf Hitler, when he dictated his 1925 book > Mein Kampf, about the use of a lie so "colossal" that no one would believe > that someone "could have the impudence to distort the truth so infamously". > Hitler believed the technique was used by Jews to blame Germany's loss in > World War I on German general Erich Ludendorff, who was a prominent > nationalist and antisemitic political leader in the Weimar Republic."_

and

> _" Jeffrey Herf maintains that Goebbels and the Nazis used the big lie to > turn long-standing anti-semitism into mass murder. Herf argues that the big > lie was a narrative of an innocent, besieged Germany striking back at an > "international Jewry", which it said started World War I."_

So Big Lie, as a term, is irrevocably linked to the Nazis as its main meaning, is not a "general fallacy", and in fact it could be argued it doesn't _describe_ a fallacy at all, but is _itself_ a fallacy devised by Hitler.

<comment><USER21> When references disagree with you about a definition, it's time to realize that there can be more than one.

<comment><USER20> Can you point me to said references? I'm ready to acknowledge them, but I don't see them. The article in Wikipedia (linked to at the start of this thread) is exclusively about the use of the term by the Nazis and how they coined it.

<comment><USER21> The wikipedia article identified it as the name of a propaganda technique. There's nothing that restricts the use of that technique to anyone in particular. Consider that people other than the inventor of the hammer can use hammers.

<comment><USER20> Yes, I understand this, and that's something that sometimes happens with words. But the use of "Big Lie" in this context (i.e. capitalized, a concept about lying) is like the use of "Final Solution": sure, it _could_ be used in another context different to what the Nazis meant by it, but how probable _is_ that? All the examples in Wikipedia are Nazi-related.

I'll be happy to stand corrected if you can point me to a single use of this concept of "Big Lie" \-- referred to unequivocally as the concept we're debating here, of telling a lie so big people won't accept it's not true -- that does not refer to the alleged "betrayal of Germany" meant by Hitler, or its related Nazi myths and propaganda.

At this point I'm only asking you for an example. To be honest I don't think there is, just as there is no other use of Final Solution, but of course I can be proven wrong.

<comment><USER21> That isn't hard at all. This one refers to it as technique used by the Soviet also.

\- [https://www.washingtonpost.com/news/made-by- history/wp/2018/...](https://www.washingtonpost.com/news/made-by- history/wp/2018/05/21/many-are-worried-about-the-return-of-the-big-lie-theyre- worried-about-the-wrong-thing/)

<comment><USER20> Thanks for the example. I wasn't aware of the use of the term in US politics/journalism. In my defense, I'm not from the US and while I of course follow some of the drama they have going over there, I'm not always familiar with the details.

<comment><USER21> I'm glad I could help.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> Shit. I got this all the time with my ex. Combine that with gaslighting[1] and you have a recipe for corn-fed, all-American propaganda.

If people repeat stuff back to you, make sure you repeat stuff back to them! Force feedback! Conglomerate!

[1] [https://en.wikipedia.org/wiki/Gaslighting](https://en.wikipedia.org/wiki/Gaslighting)</comment>


Extreme Linux Performance Monitoring and Tuning - <AUTHOR> http://www.ufsdump.org/papers/uuasc-june-2006.pdf

<comment><USER2> Thanks for this, good refresher and some more insights on performance tools such as vmstat(1) etc, although I wish GNU/Linux had a production ready tracing tool that is as easy to use as Dtrace(1), watching Ktap currently which is making some headwinds.</comment>


Taking the Training Wheels Off the Arduino - <AUTHOR> http://spin.atomicobject.com/2011/10/15/taking-the-training-wheels-off-the-arduino/

<comment><USER2> I've found the TI MSP-430 fairly good as a cheaper/rawer alternative to Arduino. It comes with Eclipse based tooling to program the microcontrollers in C or assembly.

<comment><USER3> I was under the assumption that they didn't have many timers... I just looked again and maybe they added models with more than one timer but now they have some that are up to 4 timers and still only 1.50USD. That makes things more useful.

It should also be noted that the msp starter kit is only ~4 bucks and has a full usb starter board with i/o breakouts. pretty cool stuff.

<comment><USER4> There are over 300 different models of the MSP430, ranging from the G2 or Value Line parts having 1k of Flash, a couple hundred bytes of RAM and usually one timer to the F5 series with 100-pin parts having 256kB of Flash and 16k of RAM, and 4 timers. Limiting yourself to stuff that's compatible with the $4.30 starter kit is not an accurate representation of the MSP430 lineup.

<comment><USER5> I agree. However, if you're not willing to spend money on Code Composer, IAR, or something similar, the GCC port isn't up to snuff on the 430X variants. In fact, the whole split personality of 16/20bit mode makes me want to just give up and use an ARM (Energy Micro EFM32, for instance).

<comment><USER6> The code limitations on CCS aren't too bad. Though, yes, ARM chips are awesome. STMicro has some really nice ones, with beautiful documentation and libraries.

</comment></comment></comment></comment></comment><comment><USER7> I do wonder what the future is for the Arduino with the upcoming launch of the Raspberry Pi[1]. What aspiring hardware hacker would spend $30 on an Atmel development board when there's an ARM-based board available for $25 that'll do so much more?

I think we're in for a fascinating few years, as powerful but dirt-cheap featurephone chipsets start trickling out into the hardware hacking community.

[1] www.raspberrypi.org

<comment><USER8> There are already several significantly more powerful ARM Cortex-M3 boards available for around the price of an Arduino[0][1]. The draw of the Arduino is ease of use in interfacing to GPIO/UART/i2c and in the community of accessories, documentation, and code that exists around it.

[0] [http://shop.ngxtechnologies.com/product_info.php?cPath=21...](http://shop.ngxtechnologies.com/product_info.php?cPath=21&products_id=65) [1] <http://www.sparkfun.com/products/8559>

</comment></comment><comment><USER9> Very nice! I've looked for such a guide in the past but could only find outdated or messier approaches.</comment>


Replacing Work/Life Balance with Work/Life Harmony - <AUTHOR> http://bubs.co/replacing-worklife-balance-with-worklife-harmony <comment><USER2> "Don't get misled by the hype of the hustler and mistake action for effectiveness."

"Holding on too tight to the reigns will only wear out your grip and you'll fall off the horse."

Great post. Thanks for solid advice at a time when it's needed.

</comment><comment><USER3> Thanks for the good advice; it's really helpful.

</comment><comment><USER4> I needed to read that. Thank you!</comment>


Deep Space Settlers - <AUTHOR> http://fuzzywobble.com/projects/deep_space_settlers/ <comment><USER2> That's a rather beautiful facelift. I already own Settlers twice over, so I won't be getting it, but I can appreciate the care that went into this.

</comment><comment><USER3> Cool look. Funny that resources are still "wheat" and the robber is still a robber. Why not more theme-appropriate things like "titanium" and "space pirate"?</comment>


Obtaining Antibiotics without a Prescription (2002) - <AUTHOR> http://www.nejm.org/doi/full/10.1056/NEJM200207183470319 <comment><USER2> ICU doctor here.

I frequently see complications of overuse of antibiotics. C diff colitis (1) is certainly the most obvious, but resistant pneumonias and urinary tract infections are becoming more common as well.

Many resistant organisms set up shop in chronically ill patients who see multiple rounds of antibiotics through their lives; however, in just my short 10 year history as a physician, the increasing amount of resistant staphylococcus (specifically MRSA) and VRE (2) found out in the community has changed how we treat many suspected infections.

Although some of this is due to overprescription by the healthcare profession, there are likely other selection components in our environment. Just as you can buy these antibiotics for animal use, so can people raising livestock. The FDA realizes this is a problem. (3)

Personally, the sad part to me is that our medical system is so expensive that treating routine, mild infections can cost hundreds of dollars. Thus, people search out these alternative riskier, but cheaper methods.

(1)[http://en.wikipedia.org/wiki/Clostridium_difficile](http://en.wikipedia.org/wiki/Clostridium_difficile)

(2)[http://switchboard.nrdc.org/blogs/slyutse/resistance%20graph...](http://switchboard.nrdc.org/blogs/slyutse/resistance%20graph.jpg)

(3)[http://www.fda.gov/ForConsumers/ConsumerUpdates/ucm378100.ht...](http://www.fda.gov/ForConsumers/ConsumerUpdates/ucm378100.htm)

<comment><USER3> Curious: Do these problems exist in other countries where even strong antibiotics are sold OTC?

I would guess not as bad, the culture in the US is to medicate immediately at first sign of illness. When I get sick, I try to just let it run it's course.

<comment><USER4> Or does it exist in places where medical care is cheap or free (Canada or the UK)?

<comment><USER5> Having recently been to an international Epidemiology conference, I can say that there's intense interest/concern from researchers in the UK and Europe about both MRSA and carbapenem-resistant Enterobacteriaceae.

For that matter, the current strain of _C. difficile_ which is causing so many problems was first observed in the UK and Canada.

<comment><USER6> Was it first observed and reported in these countries because they have socialized healthcare?

<comment><USER5> Unlikely, as surveillance for _C. difficile_ is pretty intensive in the U.S., and it was reported there shortly thereafter (which isn't particularly a surprise).

</comment></comment></comment></comment></comment></comment><comment><USER7> Notice our friend was already in a world of hurt by the time he went for help. Not only had he likely made his infection worse by helping it build tolerance while misdosing random antibiotics, even if he hadn't, he made it worse by waiting to get professional care.

Antibiotics are a balancing game of just the right dose. I suppose vet medicine is better than nothing at all in dire straights but if its at all possible, see a people doctor. They're good at that sort of thing.

<comment> guard-of-terra But on the other hand he skipped going to a doctor and maybe paying for the privilege.

I think he should have right to bet on it. Most times he will win.

I think that most limitations on sale of medications are bad for people and should be lifted.

I'm also not so sure that people doctors are so good.

I fail to understand how commanding people what to do with their own body is suddently okay when it comes to medicine.

</comment></comment><comment><USER8> I have successfully diagnosed and treated MRSA and upper respiratory infections in myself. I NEVER suggest anybody else to self medicate. Most people do not take it seriously enough or do enough research to self medicate.

All that being said, I think it is a shame that we live in a system where it is so expensive and inconvenient to see a real doctor that people resort to this kind of thing.

<comment><USER9> By what means did you self-diagnose MRSA? At a hospital, that would involve a Gram stain / culture/speciation / sensitivities and take a few days.

Gram stain, because it's very fast (minutes) and can tell you, e.g., that you have Gram positive cocci in clusters (thus, likely _staphylococcus species_ ).

Culture, then, to grow the bugs and see what nutritional requirements they have and what biochemical modifications they make. Catalase producing? Likely _staph aureus_.

Finally, sensitivities: resistant to oxacillin? _MRSA_.

One could imagine PCR-based tests, too, though at my institution such a test is not in use.

Getting back to my question, how did you successfully self-diagnose MRSA?

<comment><USER10> A really determined person could probably do almost all of those at home if they really wanted to, with the exception of the sensitivity test and PCR. A makeshift incubator wouldn't be that hard to fashion, TSA plates are cheap, gram stain kits are relatively cheap, and you can do a catalase test with hydrogen peroxide. I guess you'd need a decent microscope, but the hypothetical person that's gram staining their own cultures at home surely has one, right?

So the MRSA diagnosis is hard to swallow, but getting to staph aureus might be doable.

<comment><USER9> Totally agreed; I don't doubt that anyone on HN _could_ do this in their own apartment with the right tools. Many HNers probably have done this in bio lab back in high school or college. I'm just doubtful of the actual _claim_ of self-diagnosis of MRSA.

<comment><USER11> edit: misread your comment, nvm

</comment></comment></comment></comment></comment><comment><USER12> "Since these medications are not regulated for use in humans, there are no guarantees as to their quality or potency."

Also no regulation as to how they are used. Super-bugs are being bred by over- use, and a careless or ignorant individual can make his/her own infection hard to kill by using antibiotics in other than the approved way (e.g. not finishing the course).

<comment><USER13> It's not just that. Not all anti-biotics are suitable for all infections - treating a skin infection and a gut infection will tend to require different anti-biotics.

Self medication is possible and, with enough research, can be done successfully and responsibly, but for most people it's really not a good idea.

</comment></comment><comment><USER14> The fact that so many people are looking to get drugs without a prescription makes me reflect on the accessibility to healthcare in this country....

<comment><USER15> The folks in the special forces community have access to doctors. They're in the military. There are doctors in the military too and their whole job is looking after soldiers.

If you really want to get right down to it, why are guys in special forces (arguably reasonably smart, also evidenced by their figuring out this antibiotics trick) NOT going to see an army doc right away?

If I was going to be a really snarky asshole I might suggest that perhaps because it's a single-payer system the quality of care isn't that great and blah blah blah. I don't really believe that but arguments can be made both ways.

Don't be a troll.

<comment><USER16> I think maxerickson over in another subthread hit it on the head, "Active duty special forces is likely more worried about keeping a clean medical history than expense or inconvenience." These people are by definition and filtering hyper-motivated.

More generally, what makes sense for your career sometimes negatively affects other areas, but we tend to protect our careers.

</comment></comment></comment><comment><USER17> Here in Brazil, if you're friends with the pharmacist, this is easy.

<comment><USER18> So what you're saying is that Brazilian pharmacists are more corrupt than others.

<comment><USER19> Well, as an American, I was going to say friends with the vet. There's lots of potent horse medicine out there as well :)

</comment></comment></comment><comment><USER20> This actually might be good for my grandparents. They live pretty far out from the nearest town and during storms in the winter the roads can be blocked for a week or more. It seems like this would be something good to have in their first aid kit.

Are there antibiotics that keep well and are good for general infections? (Purely as a last resort if there's no way for them to get medical attention)

<comment><USER21> A very large percentage of infections are viral and antibiotics would be of no use. Hence the reason antibiotic abuse in humans is so common.

I suspect antibiotics in livestock/food supply are an even greater contributor to resistance, because they are used as preventative medicine in that sector, but really, neither is good.

<comment><USER22> So are his grandparents going to catch a cold from the trees? If they don't have contact due to blocked roads then I think they can rule out viral infections?

Or have I forgotten something.

<comment><USER23> Can't rule it out. You don't have to be showing symptoms to be a carrier, and you can be a carrier for extended periods. It's quite possible (in fact likely) that there are plenty of virus sources waiting to get you, including inside yourself.

</comment></comment></comment></comment><comment><USER24> _July 18, 2002_

Has anything changed?

<comment><USER25> Nope. I bought (fish) amoxicillin for my first-aid kit a couple of weeks ago. It says USP pharmaceutical grade, and the pills look exactly like Google image search says human amoxicillin looks. I suppose since it's unregulated they could be putting sugar or arsenic or something in the pills, but I'd imagine they'd be in hot water with some pissed off fish owners if that were the case.

</comment></comment><comment><USER26> Before I had health insurance/well-paying job, buying fishmox was the standby plan if I needed antibiotics. It occurs to me now that, even though I haven't taken many antibiotics in my life, it wouldn't matter - the bugs I would catch would be from other people and would have built up resistances to whatever I took.

Unfortunately, I told my mom about fishmox a long time ago (during same salad days) and now I sort of wish I hadn't. It's her standby plan and I'm not likely to be able to convince her otherwise.

<comment><USER27> "the bugs I would catch would be from other people and would have built up resistances to whatever I took"

This seems to imply an assumption that all bacteria are resistant, when it's my understanding that this is actually a small [in relative terms] but growing phenomenon.

<comment><USER26> True, but given my limited antibiotics exposure (I just haven't had to take them much), the chances of getting a resistant bug from someone else are much higher than my getting a resistant bug from nature (which I have limited exposure to now).

I probably could have phrased it better. Blame lack of coffee.

</comment></comment></comment><comment><USER28> This "common knowledge amongst all branches of the american special forces" is going to be a breeding ground for resistant strains.

<comment><USER29> Yes... Also, you can get anything you like over the counter in Cambodia and presumably other less developed countries ... good luck to anyone trying to regulate that.

<comment><USER25> Cambodia? It's well-known that if you want something without having to see a doctor, you can just drive over the border to Mexico and pick it up from a pharmacy. Obviously you can't get serious narcotics but you can certainly get antibiotics, prescription-strength toothpaste, etc.

</comment></comment></comment><comment><USER30> That's weird. I can easily buy erythromycin in the drugstore. I thought this drugstore was for humans, well, I have never checked...

<comment><USER9> The FDA only regulates drugs in the United States. Presumably you are located elsewhere, or if you are in the US you are likely referring to the same phenomenon described in this paper.

</comment></comment><comment><USER31> Why do special forces guys need to get medicine this way?

<comment><USER32> A guess would be that obtaining medication in an official way may affect them when it comes to selection relating to field readiness. I.e. if you are being prescribed anti-biotics it may be showing that you aren't in peak fitness so may get passed over for other fitter team members.

<comment><USER33> There are so many hidden penalties for seeking medical help. When I went through a bad breakup, I saw someone and he thought a mild antidepressant would help. I saw him twice and took the medication for 9 months.

Almost four years later, I'm trying to get a pilot license for recreational purposes and now I have to admit to having had a mental disorder, get written statements from all providers, and go through special review from the FAA. I can't imagine what a special ops guy or airline pilot would go through.

That's not even mentioning the hell I went through for pre-existing conditions as a result of this prior to the ACA.

There are very strong disincentives to seek treatment.

</comment></comment></comment><comment><USER34> Bugs and Drugs gives good local info.

[http://www.epocrates.com/e/BugsAndDrugs](http://www.epocrates.com/e/BugsAndDrugs)

</comment><comment><USER35> Or go to India, or Russia. Antibiotics are sold over the counter and (at least in case of India last time I checked) are dirt cheap.

<comment><USER36> A lot of antibiotics in the U.S. are basically free. For instance, Walmart has a $4 prescription program:

[http://www.walmart.com/cp/PI-4-Prescriptions/1078664](http://www.walmart.com/cp/PI-4-Prescriptions/1078664)

Lots of other places have similar programs/prices.

So the expensive part is getting the prescription.

<comment><USER37> The final uninsured cost being closer to $100 :(

</comment></comment></comment><comment><USER38> Garlic, colloidal silver, MMS, etc...

</comment><comment><USER39> Biseptol (Trimethoprim/sulfamethoxazole):

Amazon: [http://www.amazon.com/Biseptol-Co- Trimoxazole-20-tabs/dp/B00...](http://www.amazon.com/Biseptol-Co- Trimoxazole-20-tabs/dp/B00C7DUIHI/)

Wiki: [https://en.wikipedia.org/wiki/Trimethoprim/sulfamethoxazole](https://en.wikipedia.org/wiki/Trimethoprim/sulfamethoxazole)

Where is the news?

</comment><comment><USER40> I predict that the corporate media will run with this story and that as a consequence this source of medicine will soon disappear.

We cannot have the profits of our Most Holy Corporations drop. Cheap antibiotics will cause a drop in the Most Holy Profits of Our Sacred Corporations, and That Is Not Permissible.

<comment><USER41> >Cheap antibiotics will cause a drop in the Most Holy Profits of Our Sacred Corporations

The opposite is true: with bacteria resistant to ancient antibiotics that are out of patent and work in weeks, the only alternative will be treatment for months or years with heavily patented drugs of dubious effectiveness and long hospital stays.

Is that your preferred outcome?

<comment><USER5> Not to mention treatment for the side effects. Our last ditch antibiotics are _not_ gentle drugs.</comment></comment></comment>


Venus and Jupiter to pass in the night sky - <AUTHOR> http://www.bbc.co.uk/news/science-environment-17312354?utm_source=twitterfeed&utm_medium=twitter <comment><USER2> Serendipitous - I noticed this in the sky this evening and wondered what I was seeing - I'm not an astronomer, novice or otherwise, but it was a conjunction of stars that stood out even to a lay person.

</comment><comment><USER3> Got a really good shot last night playing outside with the kids:

<http://yfrog.com/o03xqzsj>

Not bad for a cellphone camera.</comment>


Band Discovers Leaked Song... Releases A Better Version For Free - <AUTHOR> http://www.techdirt.com/articles/20110105/20171512541/band-discovers-leaked-song-its-response-is-to-release-better-version-free.shtml

<comment><USER2> I've never heard of this band before, but I like what I hear.</comment>


Ask HN: What % of your work communication is written/asnyc vs. verbal? - <AUTHOR> Wondering what your written vs verbal communication breakdown is while working. Also which do you prefer? <comment><USER2> I prefer written communication many times more. Its a document of record that I can refer back to. I can search as a historical archive or a point of reference. Verbal communications are like farts in the wind, as in they are great when you need to make an impression but rarely stick.

<comment><USER3> This. It is good to have records of your communication. I believe this saved my job at one point.

</comment></comment><comment><USER4> Not all written comms are as async as others. Chats, once engaged upon, are expected to flow for example.

I work remotely as a principal engineer. I probably spend up to half my time doing "non-coding." I have, usually, 2 hours of meetings a day. Throughout the day, I use Slack for small questions, conversations, etc. Anything that requires formal commitment or where I don't need a same day response goes via email. Some conversations in slack get promoted to video.

</comment><comment><USER3> I think this can vary greatly from company to company, team to team, and individual to individual. I've had scenarios where it's 90% synchronous and others where it was 90% asynchronous.

Edit: this excludes scrum meetings. On the team I consider 90% asynchronous, the scrums we had were more about ceremony than communication.

</comment><comment><USER5> I work remote and the company is so small we have one online meeting per week. And one physical meeting per quarter. So 90% or more is written. I moved to a co-working space because I still need the verbal communication for sanity and motivation.</comment>


Gitlab features that are moving to open source - <AUTHOR> https://about.gitlab.com/blog/2020/03/30/new-features-to-core/ <comment><USER4> Since there are GitLab insiders in this thread, a question: has GitLab ever discussed the possibility of simply making Enterprise Edition _actually_ open source/free software, all at once, and simply continuing to charge for it like you already do? You can sell free/open-source software, and you already offer things like paid support in your pricing model.

<comment><USER5> Thanks for asking Drew and congrats the rapid progress on sourcehut.

Yes, we actually started by making making Enterprise Edition actually open source. When we announced there would be a proprietary part of GitLab people mentioned that Wordpress plugins where able to make it work with an open source license. It was a comment on [https://about.gitlab.com/releases/2013/08/22/introducing- git...](https://about.gitlab.com/releases/2013/08/22/introducing- gitlab-6-0-enterprise-edition/) but the comments there seem to have disappeared. So instead of making it proprietary we licensed it with an open source license but without offering a download, you had to pay to get access to the source code (this is similar to the Wordpress plugins and also not unlike Red Hat Enterprise Linux updates).

We were afraid that people would put up a mirror with the paid code, this didn't happen. But our customers told us that it was hard to justify paying for open source code, they got lots of questions from their managers. So we switched to making the additional features proprietary.

We tried charging for support but it is hard to make enough margin to be able to invest in the things we wanted (scalability, security, library upgrades, easy of use, etc.). People tended to cancel after they didn't use support for a year. I believe that most companies charging only for support are tempted to make the product harder to use to increase the need for support. More about the business models we tried can be found on [https://about.gitlab.com/blog/2018/11/09/monetizing-and- bein...](https://about.gitlab.com/blog/2018/11/09/monetizing-and-being-open- source/)

<comment><USER4> Thanks for the detailed answer! I'm glad to hear that some thought has gone into this. For a direct comaprison of SourceHut's financial model with GitLab, see:

[https://sourcehut.org/blog/2019-10-23-srht-puts-users- first/](https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/)

Though it's definitely _easier_ to go with the GitLab approach to monetization, I pointed out a lot of problems that these incentives set up. I'm not sure how you're going to avoid some of these problems. That being said, I imagine that it would be extremely difficult GitLab to change course so sharply at this point in its life.

To be clear, I recognize that GitLab EE, as a source-available distribution, is a measurable improvement over GitLab's closed-source offerings. I think GitLab is a valuable tool and an ecosystem without it is poorer than an ecosystem with (though, an ecosystem without SourceForge would be nice...). I hope that you guys are able to balance your incentives and stick around to provide a good service to the community, and I hope you keep it up with merging EE features into CE.

<comment><USER6> I am not sure I had ever read Gitlab's rationale for its business model outlined in this detail anywhere, and I found it fascinatingly similar to our own. I wanted to share that Canonical's 15-year experiment in business models has lead to similar conclusions: if you want to scale, you need to 1) to make it very clear why your customers should pay, and 2)take into account that buyers in general are less sophisticated in their decision making than we would hope for. I think the general move to freemium/open core models is recognition that other models are very high-risk.

I can't tell you how many times I have heard from a suit and tie buyer that they can't justify paying [that much] for open source, and even when you can answer that question in a compelling way, the message is diminished along the way to procurement. And that's erosion of margin.

You're right that there is an inherent conflict in freemium between the free version's feature set and the paid-for version, but that just means you need to weigh your options carefully along the way, and ideally come up with some simple to understand strategies/rules of thumb that your team can use when deciding where the products need to go.

Note also that it's not like other less controversial models aren't without conflicts of their own. For instance, support models set up a conflict with the quality of the product, because high quality, "It Just Works" products don't help users value support highly -- yes, even when the users are Fortune 100s, amazingly. Similarly, SAAS models are naturally incentivized to make the software complex, undocumented, hard to install and challenging to operate, lest the value proposition of the paid offering becomes convenience only, which is very hard to capture margin with for relatively low-volume B2B products.

In the end, I guess I'm saying that Gitlab's approach isn't necessarily easier; it's just much less risky and therefore scales much better.

<comment><USER7> Yeah, one of the important lessons here is: Buyers just aren't rational. Even multi-billion companies are driven by manager egos and biases and they will make dumb decisions based on prejudices.

Unfortunately, the Oracle/IBM marketing of "Opensource is trash" has proven to be very sticky so selling OSS to Enterprises companies can be a hugely uphill battle when managers think that OSS products are inherently low quality in comparison to highlghy priced "brand name" stuff. Giving them away for free with paid support is very contraproductive when your purchaser has this line of thinking - they just percieve this as "this product is so bad they need to give it away for free".

<comment><USER4> Note that I explicitly pointed out that you don't have to give it away for free - you can charge people for the source code _and_ use a free/open source software license at the same time. It does prevent you from charging a subscription fee (or at least makes it ineffective), but you can also deny them access to updates unless they pay up. Sure, someone could stick the code online somewhere else, but now customers would have to trust some random third party to forward the legitimate code to them, and this third party has to compete with your established marketing funnel.

</comment></comment></comment></comment></comment></comment><comment><USER8> Gitlab is really great for companies who wish to self-host their tools, and as a source code repository it is great at the free tier. But for small companies who might wish to migrate their issue tracking to Gitlab as well the pricing of the paid tiers is prohibitively expensive.

What would really help me is a self-hosted pricing tier that includes things like epics and roadmap management, for something like $2/user/month. No need for support, just a way to contribute to the product without breaking the bank. After all, we're already self-hosting the software, so without support exceeding that of the free tier it wouldn't cost Gitlab a thing, but it would allow smaller companies to support Gitlab financially.

<comment><USER9> You pay your employees thousands per month and rent an office for several hundreds per month. Most people here seem to buy absolutely overpriced Mac Book Pros for $3000. When you cannot pay $4 or $19 per month extra for each employee to be more productive, you have problems beyond that.

This "everything must be free" mentality is driving me crazy. And yes, $2/month/user is still ranging in the "free" region, even $4 is ludicrously cheap when you are even a minute more productive each day. Somebody has to pay Gitlab's employees and VC money wont do this indefinitely.

<comment><USER8> You seem to be well aware of the financial resources at my disposal and the salaries paid at my company. Do we have a data leak?

Besides, epics and roadmaps pushes the price to $19/user/month, which we can't afford. $4/user/month might be possible, but the epics and roadmap features are a must have at that point.

<comment><USER10> Do you guys want to chip in and create something like an open source version of Instagantt for Asana, but "Epics/Roadmaps for Gitlab".

I think something like $3000 one time payment should be enough to clone the feature from scratch.

<comment><USER11> This exists in Gitlab already.

</comment></comment></comment></comment></comment><comment><USER12> Gitlab CE is just amazing. It's hard to fathom going back to GitHub (and I wrote a book for O'Reilly about the GitHub API). The tight integration with CI rather than using external services is amazing.

<comment><USER13> Have you tried Github Actions? (I haven't, just want to calibrate).

<comment><USER14> Github actions is nowhere near as polished/mature ad gitlab ci. Github actions feels more like a "hack blocks together" than a true pipeline.

<comment><USER15> Github actions is confusing and has a steep learning curve, but the flexibility of using Docker makes it fast and reliable to _hack_ together workflows.

<comment><USER12> Are you suggesting gitlab ci isn't docker? All my pipelines are some docker variant. I'm not sure if you are just suggesting actions was done the right way with docker, but that's nothing special with gitlab ci. Can you clarify? You can even use your own docker repository with gitlab, though I'm unsure if that's something that only comes with EE (I haven't needed it yet, I just keep all my extras in the gitlab ci yaml file).

<comment><USER15> > _" Are you suggesting gitlab ci isn't docker?"_

Sorry, I'm honestly not familiar with Gitlab CI. I was just originally mentioning how the use of Docker in Github Actions allowed for amazing flexibility, which I thought was cool.

What makes Gitlab CI a better or more polished API than Github Actions? At first glance they look very similar

</comment></comment></comment></comment></comment></comment><comment><USER16> Gitlab as both a product and a company continues to amaze me with the quality and value of what they create and give to the community.

<comment><USER17> Have they started hiring shills? These reactions defer greatly from what I had seen a year ago for bad designs and high load.

<comment><USER16> No relationship to Gitlab. But do work for an organisation that uses it very heavily and gets entirely by with the open source version (plus various scripts that use the API to fill in some of the gaps).

</comment></comment></comment><comment><USER18> I had no idea there were any closed-source features - I thought Gitlab was a passionately completely open-source company. They even open-source their arguments between their legal counsel and their developers!

<comment><USER19> Please see my response above. Enterprise Edition(EE) code is open to everyone and wider community members have also been contributing to EE.

<comment><USER4> This code might not be closed source, but it's definitely not open source - please be careful about your language. It's source available. Open source software is software which meets the open source definition: [https://opensource.org/osd](https://opensource.org/osd)

If GitLab truly cares about open source (and I believe you do), you should be protecting the term from misuse.

<comment><USER5> I totally agree we shouldn't call it open source if we mean proprietary and source available. We changed the classification of our company from open source to open core a while ago [https://about.gitlab.com/blog/2016/07/20/gitlab-is-open- core...](https://about.gitlab.com/blog/2016/07/20/gitlab-is-open-core-github- is-closed-source/) Sorry for the inconsistency in this thread.

<comment><USER4> Thanks, "open core" is a classification I would agree with for GitLab. Cheers!

</comment></comment></comment></comment></comment><comment><USER20> Bummed that Pull Mirroring isn't on the list. I really want to use GitLab for CI/CD, but we dont want to store our code there exclusively. Instead we use a series of scripts to work around this problem. Would be great if the core platform just supported this.

<comment><USER21> This. Pull mirroring is a must before my team would considering using it.

</comment></comment><comment><USER22> I'm really excited by the availability of the helpdesk feature. It will help our FOSS project reduce the number of mailing lists we have (such as the security@ or some other public-facing lists).

<comment><USER5> Awesome! Getting your support emails converted into issues so you can work on them as a team tends to make it much clearer who is handling what.

</comment></comment><comment><USER23> Will these features be available in gitlab.com for free users as well?

<comment><USER5> Yes, free users with private repos have the same functionality as is in the Core edition of GitLab self-managed, the open source feature set. Free users using a public repo additionally get all proprietary features.

</comment></comment><comment><USER24> Nice set of features! I'm especially excited about the package managers.

</comment><comment><USER25> Will it be possible to customize these features?

I'd like to turn off Kubernetes integration for example.

</comment><comment><USER26> That's great! Changes I'd really like to see:

Down to starter: epics, roadmaps, HA, Free Guest users Down to premium: SAST, Dependency Scanning, DAST, Vulnerability Management

</comment><comment><USER27> This is really cool.

I just wished they had moved Scoped Labels to Free too.

And I would love that the SAST framework goes to Free too and kept have the security scanners Premium. That would allow to have basic code coverage directly in Free, without the complex static analyzers, which would be reserved for premium...

<comment> jamesh-gl Hi there!

GitLab Product Manager here. You can generate code coverage reports today and use the generated value to populate a project badge value ([https://docs.gitlab.com/ee/ci/pipelines/settings.html#test-c...](https://docs.gitlab.com/ee/ci/pipelines/settings.html#test- coverage-report-badge)) or publish the report([https://about.gitlab.com/blog/2016/11/03/publish-code- covera...](https://about.gitlab.com/blog/2016/11/03/publish-code-coverage- report-with-gitlab-pages/)).

We understand these are not the only use cases for code coverage and really just scratch the surface. We are working on the next set of features to build this category out further and would appreciate any input you might have on the issues there([https://gitlab.com/groups/gitlab- org/-/epics/100](https://gitlab.com/groups/gitlab-org/-/epics/100)).

Thanks!

-James H Product Manager - <USER3>

</comment></comment><comment><USER28> I am a GitLab contributor. I have been fighting for years for them to explain why basic features were getting shoehorned into paid tiers. This is years too late, and it falls short of addressing the source of the issue. The people who are making these decisions seem to have an incentive to restrict features to paid tiers. It's a business, I get it, but they are taking basic features that the community could implement, and locking them away in a paid tier. Sometimes a front-end only change, all the data is already available, marked as a paid feature. I used to constantly come across features I needed that had landed in a paid tier where I could write a grease monkey script to do it in a few lines of code, so I would post it as a snippet to illustrate how ridiculous it was.

<comment><USER19> First of all, thanks for being a GitLab contributor. Could you share other features you're concerned about? (If you have a link to issues that'd be great)

<comment><USER28> Description change history just landed as a paid feature.

[https://gitlab.com/gitlab- org/gitlab/-/issues/10103#note_152...](https://gitlab.com/gitlab- org/gitlab/-/issues/10103#note_152161361)

Repository push mirroring is available in CE, but pull mirroring is a paid feature.

[https://gitlab.com/gitlab- org/gitlab/-/issues/19095#note_272...](https://gitlab.com/gitlab- org/gitlab/-/issues/19095#note_272839987)

</comment></comment></comment><comment><USER29> I am using GitLab in my work environment and I really try to embrace it. But some features one just expects from a basic Jenkins setup are either missing or weirdly implemented and feel like duct-taped into GitLab.

Take for example:

\- Code coverage reports:

You can have one absolute number to get your total coverage. To get the number you have to provide a Regex deep down on the main project settings. This Regex has to match some log output of your CI job in order to be picked up, e.g "Total 87%".

Why can't GitLab collect cobertura Test reports for example?

\- Unit Test Results:

Collecting JUnit test results is disabled by default, since there is a warning about a performance issue when collecting them [https://docs.gitlab.com/ee/ci/junit_test_reports.html#enabli...](https://docs.gitlab.com/ee/ci/junit_test_reports.html#enabling- the-feature)

\- collecting multiple artifacts as HTML pages:

to circumvent the above downsides, you can get creative, and generate HTML websites of the Unit test and Coverage reports themselves and publish them somewhere. An ideal place would be GitLab pages.

But you are only allowed to have one publish job for GitLab Pages. And this publish job has to have a special name so it is recognized for publishing GitLab Pages. The artifacts you want to publish have to be in a special named folder in order to publish them. So you fallback to some hackery by using "mv,mkdir"

[https://about.gitlab.com/blog/2016/04/07/gitlab-pages- setup/...](https://about.gitlab.com/blog/2016/04/07/gitlab-pages-setup/#add- gitlab-ci)

These were some examples which I find not that exotic for a CI setup and I know from previous experience that Jenkins handles all these with ease. To circumvent this shortcoming, we introduced SonarQube.

I feel that people often are drawn to a shiny, small GitLab CI yaml and are happy to get started so fast. But again having Jenkinsfiles with shared libraries, which you can program in Java and Groovy, is superior to the next yaml include/extend you are going to add.

My 2cents are that:

If you are a solo developer or a small company Gitlab might be fine for you. When your company is larger and you want to be able to share knowledge using shared libraries, have a streamlined CI setup with GitLab includes from multiple departments, GitLab gets tough.

How could one be confident to use for example their 1-click deployment (autodevops) Feature if the implementation of CI basics like collecting test results and coverage reports have this weird taste to it?

I wish these features will get better and please don't take this too harsh. My tone might sound worse than it is.

<comment> jamesh-gl Hi there!

GitLab Product Manager here. I really appreciate the feedback on those features and it helps inform some upcoming work to make them better. The team is currently working on improvements to JUnit parsing ([https://gitlab.com/groups/gitlab- org/-/epics/2854](https://gitlab.com/groups/gitlab-org/-/epics/2854)) so we can enable those Junit reports by default.

We are also working on the next set of code coverage features to build this category out further and would appreciate any input you might have on the issues there as we're prioritizing and scheduling for the next few milestones ([https://gitlab.com/groups/gitlab- org/-/epics/100](https://gitlab.com/groups/gitlab-org/-/epics/100)).

Thanks!

-James H Product Manager - <USER3>

</comment></comment><comment><USER30> All not very relevant. They keep the core business features (like merge request approval) carefully out of the OSS edition. And they haven't fixed the pricing for their premium offering either.

<comment><USER31> Relevant is subjective. Merge request approval is not something a single contributor needs for example.

You can still get it by paying for it. In the end GitLab is a business, someone needs to pay something. As developer who runs a GitLab server for personal projects I don't miss any paid features.

<comment><USER32> Rather makes sense, because for many open source projects with a single or handful or contributors it's not a very important feature, but for larger teams (i.e. companies) it is, which ensures they pay their fair share while still keeping the product available for free for most of us.

<comment><USER33> Still, having _any_ features that are propritary and thus off-limits to contributors does not create a good community atmosphere.

Say as an example that Debian, which has a big user of GitLab wanted this feature, so the Debian project contributors create all the patches & submit them for inclusion in the open source part of GitLab. Normally, a project would welcome any (presumably) well written patches like this. But with open core project this creates an instant conflict of interest.

Either GitLab takes such patches, loosing their proprietary edition exclusive feature & possibly even compatibility with their closed source implementation of it. Or they reject the patches, presumably loosing a lot of goodwill with the community and forcing Debian to maintain those patches for ever in their own fork of GitLab.

All in all, I don't see open core companies like something to invest ones contributor time to due to this & more importantly like something to use and make you open source project to depend on.

<comment><USER32> The alternative is GitLab not being able to hire developers to actually build GitLab since the "kindly ask to please pay"-model doesn't really work very well.

"The community" is often vastly overrated anyway IMHO. Patches are always good, of course, but people who actually consistently invest time in a project are exceedingly rare. You can't build a product based on sporadic patches. Besides, a lot of the time "the community" is just users (people with no contributions) complaining you're not doing stuff right.

Unless you have a viable (preferable proven) model that allows GitLab to hire developers _and_ keep everything 100% open source, it seems to me this is the best and most balanced option. To the best of my knowledge, such a model doesn't really exist.

I continue to be surprised at the hesitancy (or even outright hostility) whenever someone tries to make an economically viable open source product, which usually involves things not being 100% open source because turns out, that's the only way to make things viable. "90% open source" is a hell of a lot better than 0% open source in my book.

<comment><USER34> The oldest viable and proven business model where you can keep 100% open source, is to sell support contracts and warranties. This model is harder for your average SaaS company to pull off but provides much better ROI if you can actually do it.

<comment><USER32> It only works well if you have a decent amount of large enterprise customers (like RedHat); I don't think it will work out well for GitLab, which is mostly aimed at small-to-medium businesses. I don't think it's viable for most projects (otherwise they would be using it).

Even if it is viable, you're usually leaving a lot of money on the table, and even Red Hat – the poster child of this model – does stuff like releasing updates to paying customers first.

<comment><USER34> You are always leaving money on the table. The choice of business model is only a decision of whose table you are going to leave it on. The downsides of the open core model have already been mentioned here. I am not suggesting that GitLab change their business model, I don't have any opinion about what they should do. But I will say that releasing updates to paying customers first is still consistent with being 100% open source, as long as those updates are still released to them under an open source license.</comment></comment></comment></comment></comment></comment></comment></comment>


Starters and Maintainers - <AUTHOR> http://www.jlongster.com/Starters-and-Maintainers <comment><USER2> Open source is really hard.

* Sometimes, issues are just questions that belong on StackOverflow or any other forum online.

* Often people suggest pull requests that don't really fit what you see as the roadmap for the project, you have to be polite and respectful.

* There's the case of beginners trying to jump in, if your project is something that appeals to beginners (eg:Rails), you are in for a whole bunch of other issues supporting the getting-started.

* There's a lot of stress involved with managing all of this, if you are alone in the project it can get pretty overwhelming.

* Finding collaborators on open source projects is not easy as well, most of the times the project README doesn't suggest that collaborators are welcome and appreciated.

* Forking creates a lot of fragmentation.

* I can think of many projects that lost the steam. Resque is the perfect example for me, even with new contributors it failed to get going and Sidekiq won.

* We still need to figure out a reward system for open source to prevent maintainers from losing steam along the way.

<comment><USER3> _Sometimes, issues are just questions that belong on StackOverflow or any other forum online._

Exactly. GitHub offers no support for on boarding new issues, so a lot of well meaning misplaced questions can pile up quickly. There's no GitHub issues MOTD or "have you tried X, Y, Z first?" or even a way of saying "issue tracker is for provable bugs _only_ — not for asking why our software doesn't compile on your 16 year old version of RedHat."

 _We still need to figure out a reward system for open source_

The universal currency for exchanging units of time for units of economic productivity is money. (and not "oh, my employer gives me $5 a month to donate anywhere I want, we are so special!" but rather, $200k to $3m per year to projects that help run your company.)

<comment><USER4> In other news, people continue to be surprised that demand for free labor outstrips supply :D

We've discussed this here before, but I bet the majority of companies are parasites. Heavy consumers of open source, with virtually 0 contributions of money or time. I think we should resolve, particularly those of us in a position to make it happen, to donate to open source projects.

I do (and I stay anonymous for multiple reasons) run a small open source ML project. I ignore virtually all support requests, but if you are a heavy open source contributor, you will get a response. You should mention that in emails; I'll go out of my way to help you (and often even promptly!)

<comment><USER5> > I ignore virtually all support requests, but if you are a heavy open source > contributor, you will get a response. You should mention that in emails; > I'll go out of my way to help you (and often even promptly!)

Seems like a very sensible policy but will people really volunteer that in emails with no notice? Or do you state that somewhere in the project documentation? I'm a reasonably active open-source contributor but it wouldn't occur to me to mention it when sending an email to a project in an unrelated space.

<comment><USER4> I actually do mention I'll make an extra effort for you if you contribute to OS. I added it after recognizing the name of someone who emailed me, realizing I'd been using software he wrote for years, and feeling like I owed him an effort.

That said, I think it never hurts when asking an OS contributor for a favor to point out you do the same, even to a completely unrelated project.

</comment></comment></comment></comment></comment><comment><USER6> >Well, so much for catching up on these issues tonight. Maybe I'll just add DEPRECATED to the README, that'll fix it.

Please, please, if you have too many projects like the author or myself, put a huge note in the README that it's not maintained. If you're lucky, there'll be an active fork you can point people to.

I wish GitHub had a proper UI for deprecating/abandoning projects and setting another fork as the canonical source.

<comment><USER7> While not a GitHub UI feature, isitmaintained.com [1] comes close to providing a quick overview about a project's status. When choosing open source libraries, I always go there first: [1] [http://isitmaintained.com/](http://isitmaintained.com/)

<comment><USER8> That is pretty neat and I love seeing more project statistics- however, fair warning, I was a bit surprised it doesn't scan issues older than 6 months.

As a result, if a project closes all issues in either a day or ten years, it will report that the mean time to resolution is 1 day and not essentially ten years :)

</comment></comment></comment><comment><USER9> I empathize with the author. The root of the problem can be interpreted as the fact that a well maintained production-ready library is almost an engulfing charity service for the author. Ironically, economically, the optimal solution is for the masses benefitting from the library to return some of that benefit (perhaps in monetary form) to the author. But culturally this is not what free-software is about...

That's the irony and inefficiency of open-source software.

<comment><USER5> > the optimal solution is for the masses benefitting from the library to > return some of that benefit (perhaps in monetary form) to the author. But > culturally this is not what free-software is about...

There's been quite a bit of improvement in that problem space. Crowd-sourcing is now considered by users a natural way to fund new work. So much so that in more user facing apps users are constantly asking about it if you don't have a campaign already. There are also micro-transaction solutions like gratipay (previously gittip) that are more open-ended and continuous which probably works better for lower layer projects and when developers don't want to fiddle with managing crowd-sourcing campaigns. Github could very easily own that space if they implemented something like "give x$ per month to every project I've starred".

<comment><USER10> > Github could very easily own that space if they implemented something like > "give x$ per month to every project I've starred".

I would love this. Has this been discussed anywhere?

<comment><USER11> We do have gittip, flattr, etc ... this doesnt seem to have produced much success.

Patreon does seem to be developing a bit of a traction here too now. "I work on xyz, keep me funded so i can continue working on xqyz"

<comment><USER12> I think it's because it's not seamlessly integrated into Github and instead relies on external services that aren't intercompatible. If Github integrated/bought one of these services and made everything work smoothly with their billing system, I think many people would love to contribute. Maybe even make "corporate" contributions, although I don't know how that would work.

<comment><USER13> I'd much rather have a 'corporate' version where you could sell commercial licenses through github for $250-$350 to bigcorps and VC funded startups than a gittip where you can beg for 5 cent donations from developers.

</comment></comment></comment></comment></comment></comment><comment><USER14> I make 2 compromises in my open source software work in order to keep up with all the projects I start and at least do a decent job maintaining _some_ of it:

1\. I don't support old stuff. No old operating systems, no old dependencies, no old compilers, etc. The answer to all support requests of the sort is "sorry, I don't have the time or funding to support versions below XYZ."

2\. I'm not afraid to roll the major version number of my software. If I make a design mistake, I fix it without regard for backward compatibility, and then I don't support older versions.

These two things really make a big difference in lowering the difficulty of support without compromising the quality of at least the latest version of code. And if the users are using the latest version of everything and need support, great! They probably have such a similar environment to my own that I'll have no problem reproducing their issues.

<comment><USER15> are you the three.js "maintainer" ? My code breaks every time I update three.js I would be fine with that if the release notes would point that out directly. It's really a nice library but it would be great if he handled the project a little bit more "enterprisey"

Sorry - I had to vent.

<comment><USER16> Bummer. Know what enterprises have, though?

</comment></comment></comment><comment><USER17> > 9 new issues since I last checked. 2 new pull requests. Hopefully most of > the issues can be closed, and the pull requests are trivial. Ugh, nope, > these are some significant changes. I'm going to have to think about this > and engage (politely) in a long discussion. They also didn't update the > docs, and this is a breaking change, so we'll have to figure out how to tell > everyone to upgrade.

>/.../ who am I kidding, that would just stress me out more. It's not like I always have time to respond. At least now I can pretend like this doesn't exist when other things are stressing me out."

So much this. This is why most of my opensource projects come in the form of "Here's the code, if you don't like it, fork it and maintain your own damn fork". In 5 years of putting code on GitHub I've probably merged less than 10 pull requests on projects that don't directly put food on the table.

<comment><USER18> It's unrealistic for people to throw drive-by PRs and expect them to be merged. I can't imagine many cases where a drive-by PR _should_ be merged, maybe:

* Legitimate bug fix with clear explanation. * Non-breaking enhancement that maintainer agrees with (low likelihood of agreement)

Any other use of PRs (e.g. breaking change), if acceptable at all, should be coordinated with the dev team before expecting it to be merged. As the article says "engage (politely) in a long discussion." I'm not convinced that a PR should be the starting point for that long discussion, but that's how the github workflow works. imho the bar should be set very high for this kind of PR.

Another use of PRs is: here's an interim patch that I made, that I don't necessarily expect you to merge, but maybe someone else will find it useful for developing a mergable patch. I see that quite a bit, and I think it's useful.

The Github workflow doesn't really model intents of the above scenarios, or varying policies of different projects. I think it contributes to the problem.

</comment></comment><comment><USER19> Another interesting wrinkle is that starters often get the credit or notoriety for the project, even if there is a large group of others now maintaining and supporting the project. Not to say that the project starters have abandoned the project or did anything nefarious, but when you think of projects like Rails or Backbone -- you think of DHH or Jeremy Ashkenas, not necessarily the other core committers now involved.

<comment><USER20> That's part of the guilt, too. We over-emphasize starters, when maintainers (who very well could be the same person!) should really get most of the credit. Well, at least equal. Unfortunately social dynamics tend to glorify single people.

</comment></comment><comment><USER21> Lol I just read this after a "break" working on my winter break on a project I "started" almost three years ago. I checked in with the community and it turns out they're still using the junk I made years ago, it's helping people be really productive, but nobody understands how to modernize it.

So here I sit three years after "starting" the project and basically going back to work. Now I've spent the last 8 days straight coding about 6 to 10 hours a day on my vacation to "start" it again, but way cleaner. My two goals are, one I want my wife to be able to use it (ease of use) and second I want to empower the guy who picked it up to be great at maintaining it after I eventually return to the real world.

I learned years ago that I am good at the blank page, the staring back at you empty cursor is my favorite time. The clay is fresh and the images dance in my head of all the potential of that flashing cursor. I'm not the guy who really enjoys wading in up to my ears into a million lines of code and refactoring it to some new vision. I can do that but it doesn't get me out of bed every day at 5am on my "vacation".

</comment><comment><USER22> If you're going to abandon a project why not just add collaborators? Add anyone that submits a PR. Let them take over the future vision of the project if you're no longer interested in it. I think that's good policy anyways, anyone who takes the time to submit a PR (and I deal with so many people who submit a million issues but never will make even the slightest change) has an investment in the project that you may no longer have. Let them own it.

<comment><USER23> alternatively, let them fork it and put a link to their repo in the README

</comment></comment><comment><USER24> > I'm going to be clear that code I put on github is experimental and I'm not > going to respond to issues or pull requests

Stating the project maturity is nice but not that important - it's pretty easy to glance through a repo's code, commits, issues and PRs and judge the project's maturity and how many people are using it and how likely ongoing investment is to occur over the next couple years. You can also look at the maintainer's online presence, blog, talks, social media (be it a person, a team, a corporation, startup or nonprofit). Pretty easy to predict what their priorities are and will be.

People get bit by project maturity only once, and i figure by this time next year it will be common knowledge that for your random semi-popular github project on social media, maintenance is never implied unless promised, and even then not really unless everyone's incentives align.

<comment><USER25> Yeah, it's all about what have you done for me lately on github. Even extremely well maintained libraries suffer from bitrot if they're not touched recently.

</comment></comment><comment><USER26> Maybe that could be a solution: a platform enabling people to offer paid support for their open source projects – [https://news.ycombinator.com/item?id=10805236](https://news.ycombinator.com/item?id=10805236)

When things become popular, it would be much easier to find and recruit maintainers if there was some regular monthly income attached to it.

</comment><comment><USER27> I've started projects that were contextual to the stuff I was working on at the time, but once I stopped working on it, there really wasn't much point in maintaining the projects anymore. I feel quite bad about it, but I can't remove it either since I show it to potential recruiters as well.

Even funnier was one of my projects gained interest in the Android community, and I don't even do any Android stuff, which made it almost impossible to support them.

Definitely a tip of the hat goes out to those who stay the course and maintains the projects they start. It's a gruelling journey

</comment><comment><USER24> The thing is, people want their new project to get popular, because it validates them and is great portfolio and is motivating to work on, but you can't just stop once you have users. a lot of maintainers just quit when they got the users and used them for what they wanted. That's not very cool. So I don't think the project maturity is so important but rather that the project maturity not go backwards. If you're promoting your stuff on social media, positioning your work to be used by beginners, it needs to be maintained at that level until the users move on. I'm not aiming at anyone in particular right now, im just saying as a thought experiment, what if you make some great thing library and everybody loves it then a year later some idea gets back ported from Elm or ClojureScript and now someone else's stuff is exploding. Are you gonna move to the shiny thing and burn the people who believed in you? It's an impossible choice. I think a lot of people are gonna get burned on this in the next two years and JavaScript world will move back towards frameworks rather than libraries.

<comment><USER28> > I think a lot of people are gonna get burned on this in the next two years > and JavaScript world will move back towards frameworks rather than > libraries.

I don't think so.

Most of the companies I have worked at have the resources and expertise to maintain a couple of open-source libraries if the authors move along to greener pastures.

On the other hand only very large companies have the ability to maintain abandoned frameworks.

It is also a lot simpler to change libraries than it is to change frameworks.

</comment></comment><comment><USER29> 99% of noise is from email notifications for conversations on issues.

Turning off Github Issues is the easiest way to change the expectations.

On another note, GitHub Issues should be Opt-In instead of Opt-Out for Repo owners.

</comment><comment><USER30> There was this interesting thread a while ago of someone deciding to give commit rights to anyone who made a pull request. As I remember it, it works out well for the author: Less maintainer time, and the quality of the PRs improved immediately. Unfortunately, I have not been able to dig up the thread.

</comment><comment><USER31> This reminds me somewhat of "Commandos, Infantry, and Police" [http://blog.codinghorror.com/commandos-infantry-and- police/](http://blog.codinghorror.com/commandos-infantry-and-police/)

<comment><USER32> Yes - or pioneers, settlers and town planners of Simon Wardley: [http://blog.gardeviance.org/2015/04/the-only-structure- youll...](http://blog.gardeviance.org/2015/04/the-only-structure-youll-ever- need.html)

It's hard to have to play all the roles.

</comment></comment><comment><USER33> This resonated with me so deeply. I have played this conversation over and over in my head, wondering "why?" ... but somebody has to. It's often a labor of necessity, not love.

</comment><comment><USER34> I had similar feelings, so I don't open source things anymore. I wrote about it here: [http://brianknapp.me/open-source-guilt/](http://brianknapp.me/open- source-guilt/)

For me, open source projects aren't worth my free time. I'm fine with giving code away. I'm less fine maintaining it years later.

<comment><USER35> Back in the day, open source projects were just a tarball on some ftp server. Maybe, just maybe, the README contained an email address to send patches to.

That probably wasn't such a bad model after all.

If you worry about endless support via email, create per-project aliases that at some point may autoreply "this project is not supported any longer. Feel free to set up your own fork".

</comment></comment><comment><USER36> Aside from the different "tipping" services, is there a way open source authors and maintainers can raise funds _without_ doing crowdfunding? Something that let's them sell something to raise funds like when schools sell chocolates? (:

</comment><comment><USER37> If you don't have a vision for your open source project, then I agree that you probably shouldn't be maintaining it - In this case, it's better to hand it over to a different maintainer who does have a vision.

</comment><comment><USER38> Please just keep maintaining nunjucks :)

<comment><USER20> Nunjucks was one library that I finally transitioned to another maintainer, carljm. I don't maintain it at all! I did for about 3 years though, so it was definitely time for someone else to step in, and he's doing a great job.</comment></comment>


Why JavaScript Still Sucks - <AUTHOR> http://boronine.com/2012/12/14/Why-JavaScript-Still-Sucks/

<comment><USER2> He explains his options at the end, so I don't know why he is saying it sucks :) JavaScript is improving but is the bloody vendors that keep lacking it behind. That is why TypeScript is awesome, they are bringing ECMAScript 6 to all browsers in native JavaScript form.

<comment><AUTHOR> In the title I am referring to JavaScript as it stands today, rather than JavaScript as a work-in-progress. As for TypeScript, I actually overlooked its relationship with ECMAScript, it's very cool indeed. I updated the post a bit.

</comment></comment><comment><USER3> I don't think that that much analysis is needed. JavaScript is simply a horribly-designed language.

Furthermore, it is inherently impossible to improve it. The only way to improve JavaScript is to throw out everything that's there. At that point, you aren't dealing with JavaScript any longer.

The obvious solution is just to offer Python and/or Lua embedded within the major browsers (even if that doesn't include IE right away). They are both sensibly-designed scripting languages that are essentially free from the problems and stupidity that we see in JavaScript. We might as well use them, and at least leverage some of the code that already exists for them.</comment>


The Truth About Google Glass - <AUTHOR> http://techcrunch.com/2013/03/06/the-truth-about-google-glass/

<comment><USER2> Re: Or maybe Glass will end up like the Segway – kind of cool, but vaguely useless. Who knows? What am I? A mind reader?

How would being a mind reader help him accurately predict the future?

<comment><USER3> He could take a large, random sample of what people actually think of such a device.

</comment></comment><comment><USER4> TC is learning from BusinessInsider now? I've always hated their "The Truth About..." articles, because they are so misleading, and they just use the word "truth" to promote their bias.

</comment><comment><USER5> Title change suggestion: "Google Glass Predictions"

</comment><comment><USER6> very hilarious, if this works like this with it anyone can talk on any topic.

<comment><USER2> just like now, anyone can post on any forum about anything. that in itself doesn't make the conversation the least more interesting/etertaining/insightful though</comment></comment>


Ask HN: Startup is Failing, Now What? - <AUTHOR>

Throwaway account.
The startup I joined a few months ago is failing.  I don't know what to do.
The writing is on the wall, I know it's coming.  It's only a matter of how quickly our cash flow collapses.  We are a small team in NYC.  Ten people total.  We've been cutting back more and more from the day I joined three months ago.  It is becoming apparent that things weren't quite as good as I was lead to believe when I was hired.
Our CEO just came out of his office and then left.  I think he has been crying.  He keeps trying to reassure us that things are going to be ok, but people are losing faith.
Anyone have any insights on:
-Does it reflect poorly when I'm interviewing that I'm trying to jump ship?  I wasn't a founder and don't want to be perceived as a quitter.
-Should I just ride it out?
-Any great blog posts already written on this subject?
Thanks. <comment><USER2> I've stuck it out to the very end a couple times. Once I was the last guy to lock the doors and walk away, after the CEO, after all the management senior to me. After the cleaning crew.

It really comes down to what you can afford. You've stated (obliquely) that your pay is being reduced. Can you afford to stick it out at the reduced pay? What is your opportunity cost for staying, do you think you can get a job at Square or some other too good to pass up opportunity?

Can you go a month without pay when shop closes up? Can you go three?

Some things to keep in mind: Sometimes when companies are in trouble they get bought by other companies. This doesn't mean your options will be worth anything but you will have gone through an acquisition which can be a valuable experience.

Sometimes they get shut down or liquidated: Still valuable experience (just once though, please.)

Sometimes lightning strikes and your startup comes roaring back to life. This one really depends on the team and your leadership, not to mention whether there was anything to begin with. If the team is broken and has lost hope then it's less likely anyone will find that inspiration that can change everything. If people still have fighting spirit you might have a chance.

I'm sure your CEO is wracking his brain trying to figure it out. His job is the worst job you can have right now. While you see a company failing, he sees himself failing. The simple fact is that most startups fail. They are experiments to begin with. Learn what you can.

The thing is, everyone who sticks around will have gone through something very difficult together, regardless of the outcome. Doing so makes those relationships valuable and long-lasting. A lot of "success" comes from solid relationships with people you can trust.

Tech startups are hiring like crazy right now. Definitely find out how much time is left. Time is the only thing in life you can't get more of but that doesn't mean you shouldn't choose to do something really hard once in a while. If the remaining runway is pretty short then it's unlikely you'll miss out on the rest of the current tech boom.

So, figure out how much time is left before the company ends then weigh the opportunity cost of staying versus where you might land if you go.

Oh and if someone offers you a job at something like Square that has the potential to change the course of your life through the amazing people you'll get to work with, the network you'll build and/or massive potential financial opportunity: TAKE THE JOB.

<comment><AUTHOR> This is what I needed to hear. I need to balance the opportunity costs associated with my options.

I re-read this entire thing two or three times. Great stuff to consider. Thanks.

<comment><USER2> Glad I could help!

</comment></comment></comment><comment><USER3> Did you take equity or a promise of equity? If so, flat out ask how things are REALLY going.

If you're just taking $ for hours and you like the work, stay for as long as they keep paying you but still ask if there are any problems. If they punt and don't answer or you don't believe they're being honest with you then start looking at your options for getting out of there.

You have to know that they'll drop you as soon as the cash runs out, so you owe them NOTHING.

<comment><AUTHOR> I took the promise of equity, cash and benefits. Two of which are being reduced, one of which had dwindling value.

Good advice, thanks.

</comment></comment><comment><USER4> Heres my personal tale of attempting to stick it out for as long as possible. It's quite a long read.

Not saying it'll be like this for you, but you need to decide when its time for you to call it quits, and not necessarily get trapped into thinking you can single handedly hold up a sinking ship

<http://lookingbackaretrospective.posterous.com>

<comment><AUTHOR> Perfect. I'll definitely read through this.

</comment></comment><comment><USER5> No one wants to be the last person on a sinking ship. Yeah, being a rat stinks -- but it beats drowning. And I think most people will understand that.

On the flip side - if you're looking at other startups, they may view that as a potential negative. Things are always darkest before they get better and sometimes you need to stick with it until the end. Just once - to prove you have faith and loyalty; that you have the capability to see it through.

Only you can weigh the two choices but if you're in NYC tech scene there are a million great jobs; either choice and you'll be employed in no time.

Oh, and we're hiring!

<comment><AUTHOR> Those are definitely the two options I'm weighing.

</comment></comment><comment><USER6> You joined three months ago.

Things were already going downhill.

The company is not meeting it's explicit obligations in regards to your salary and benefits. It is unlikely to meet any promises to grow your equity either.

In my opinion, it was bait and switch. The signs were there for management when you were hired.

There is nothing wrong with leaving sooner rather than later. It's unlikely that you are forgoing a virtual 10,000 shares of Microsoft in 1984. Time to cut your losses.

Good luck.

<comment><AUTHOR> This has been a reality check and forced me to look more objectively at my situation. Thanks for the advice.

</comment></comment><comment><USER7> I'm sorry to hear this - it's certainly going to be a tough few weeks for all of you and especially the founder. If there's no way to pivot or salvage anything, I think interviewing is smart and any recruiter would understand why you're looking for a new job! Best of luck.

<comment><AUTHOR> I'm hopeful people will be understanding.</comment></comment>


Helping Out With the GPU Shortage (Price Tracker) - atoz-tracker https://www.reddit.com/r/buildapc/comments/84t2sb/new_gpuhardware_price_tracker/ <comment><AUTHOR> Do you know what else helps with the GPU shortage? The current market! There will be lots of damaged, cheap GPUs on second hand markets in the coming weeks and months if this continues.

<comment> atoz-tracker That's certainly a possibility! There's also a slightly different reality, people continue to mine while it's still profitable.

While there are certain places in the world where the cost of electricity currently makes mining unprofitable, this is not true w.r.t the majority.

Sure, people who are afraid of the rollercoaster might sell, but the big fish will gladly eat them up, and at a sizeable markdown. In all honesty, it's hard to imagine that people would stray away from making passive income while still feasible.</comment></comment>