It's not a phenomenon; users are not out to oppress or censor anyone. These types of stories are terrible in terms of quality of discussion, and provide almost nothing to satisfy one's intellectual curiosity. This whole thread is he said / she said feces-flinging, and many people would rather have interesting articles on the front page. It's essentially tabloid gossip, and has been discussed to death on reddit / twitter already. I'm not taking sides here, I could care less about GG or a dev who gets into twitter fights. Here's what would be useful to post instead:

- Github link to a crowd-sourced code of conduct anyone can help improve

- A compilation of useful tips for interacting with / contributing to open source projects

I lost braincells reading this thread, and that's not why I visit HN.

Yeah, I do agree that HN could handle the discussion more productively. But preemptively flagging stories as categorically unacceptable for HN seems like a way to make that never happen.

There is a good discussion to be had about, say, whether an open-source project should welcome someone whose views make existing members uncomfortable, how much voice an inactive member should still have, how to handle trademarks in a spirit of community while still making names meaningful, what authority a core team should have and when they should feel comfortable removing active contributors, etc. Discussing them in the context of this incident would inform those two discussions you suggested; otherwise we have people constructing codes of conduct from intuition and first principles, which seems most likely to be counterproductive.

It is somewhat unfortunate that we don't have a response from core or the Foundation about how they saw things from their end and what their pressures were. But admittedly it's a fairly large cultural shift to be willing to talk about these things openly.

Agreed! I think part of the problem could be that the first, say 10-20, comments on a controversial story won't be very good. This makes people flag it before (hopefully) a lot of genuine thought and effort goes into the comments. I'm not familiar with how flags affect a post's rank on the front page. Thinking out loud, a system where the first user flag has minimal impact and the impact grows very slowly with each additional flag could work.

Even though I find it uninteresting, it's arguably necessary in the same way people post here when they can't reach someone at a large company they're having issues with in the hopes that an employee will come to their aid.

Hm, there's a meta-question of whether the purpose of HN is stories or comments. I think the story itself is worth the hacker community reading, regardless of the quality of the comments.

A specific flag for "the comments will turn into a flamewar, but we shouldn't let the threat of a flamewar silence the story itself" might be useful. And in this case, 'dang manually did take action to curb low-quality comments. Having a user-initiated flag that restricts posting by users postdating the story, increases the waiting period on replies, etc. (and alerts moderators) might be more useful than simply removing the story from the front page (but allowing people to come in via external links).

It'd be great if more startups entered the car-board computing field. Mounting an Android tablet, rasberry pi or arduino in the dash isn't very complex, and simpler to update. I wouldn't mind seeing a brief boot screen if it was linux and the stereo was a separate unit with aux input.

The thing I want most when driving a vehicle is the joy of having to look over at a touchpad to remember exactly where the controls are, and if they've moved significantly since my last software update.

I don't care how fancy your software is, I require PHYSICAL KNOBS AND BUTTONS. No exceptions.

Some would rather nitpick this interview than see the good in it. This is disappointing considering it covers practical and useful topics.

- Ted's progression from first time user to contributor. Start with small diffs in an area you're interested in, and build up if you can.

- Re-factoring programs with a strong emphasis on maintenance and security. Technical debt is real, and you certainly don't want it in an OS.

- Balancing more menial tasks (maintenance to the existing platform) with interesting additions (new security techniques).

The peace of mind from knowing an upgrade won't break or fail, and that security is taken seriously is refreshing. Give OpenBSD a shot, read some of the source or man 9 style (it's more informative than HN arguments).

While this is true, it's pretty easy to infer from gps. If there's a 10 minute ETA and you just went over the proverbial train tracks into the bad side of town, or you're familiar with the surrounding towns, it's not difficult.

Simple solution: shift earlier, since you can shift up at 2k (before the turbo really takes off) without lugging the engine at all.

Complex solution: Chip the engine - some people prefer a smoother power curve, which can be achieved with a tune.

I don't feel like driving a manual in a busy city, and much prefer letting the more fuel efficient dual clutch transmission do the work.

Understandable (except for the "more fuel efficient" bit), but with your reply to @huuu in mind, being able to select your gear (and keep it in that gear) would eliminate any unexpected surging. Dense traffic isn't a lot of work in a TDI, because you don't need to shift frequently if at all. In my experience 2nd gear covers between 10-35mph comfortably. I have a 1.25 hour commute that's a mix of stop-and-go in small towns and highway, and the TDI is great for every bit of it.

Everything I've seen suggests the dual-clutch automatic transmission is more efficient than the manual, including VW's own figures. It came as a surprise to me, but a nice benefit for other factors.

I imagine that yes, being able to keep it in low gears would have helped, and indeed putting it into manual mode for some of the parts I found the worst (rapid turns from one busy street to another) helped, but it put it in the "More trouble than it was worth" category.

That being said, the TDI was a great car, and a serious contender for my money. I just preferred the GTI a bit more, but given I love the GTI, that's good company to be in.

The published numbers say that. The real world numbers say very much otherwise. The manual CRUSHES the DSG, often by 4-5mpg or even more for some drivers, especially on the highway.

It's geared lower, for one thing, only 2000rpm at 75mph.

FWIW, I traded in a 2012 TDI with the DSG for a manual Mk7 a few days ago. Love the stick, although it's taking some getting used to (this is my first manual).

Also in the manual's favor is the $1,100 cheaper upfront cost and not needing a ~$400 transmission service every 40k.

Interesting. I'm rather fond of my DSG, and manual was a little bit of a non-starter because my wife wanted a car she could drive, and learning stick in DC is...a terrible idea.

Having seen a video[1] of a drone armed with a paintball pistol (and its precision), I would say that it will be much sooner than expected. Despite the fact that I'll probably be put on a watch-list for saying this, it would be the perfect crime. There would be no weapon left at the scene (provided the drone returns to its base), as well as no DNA samples. Anyone who could rig and pilot such a drone would probably be smart enough to leave minimal evidence related to motives, purchases, etc.

[1] https://www.youtube.com/watch?v=Jplh7uatr-E&t=138

This trick is very helpful, but I would argue that there are still a lot more parentheses due to almost everything being written as a function in lisp. When I started programming in Racket arithmetic and comparison expressions tripped me up frequently. My tip to beginners in this area would be to use the dot-notation first, then switch to the standard way once comfortable. for example:

    (20 . > . (10 . / . 5))

may be more clear than

    (> 20 (/ 10 5))

in addition to what logicallee said, it's common for inexperienced programmers to (poorly) "re-invent" concepts that were discovered in the past by those "smart old people". This is caused by a combination of factors, and one of them is the belief that one can solve a problem single-handedly without studying the fundamentals and previous strategies. Ignoring the work of the masters is a good way to start from scratch and do worse.

Sometimes, it's also a way to invent things that were considered impossible.

Yep! Also, reinventing what existed before (intentionally or by accident) can give you a better appreciation for what was invented in the oast and might be the best way of finding out about it (if you don't know the name, for example).

The company I bought my mechanical keyboard from sells sets of O-rings that go under the key-caps[1] to reduce noise. They won't fit on every keyboard, but one could easily find different O-rings that do. I don't use them because noise isn't an issue in my situation, and I enjoy the sound of the key bottoming out. For those in open offices though, they might make the difference between tranquility and having your keyboard used as a doorstop(!)

[1] http://www.wasdkeyboards.com/index.php/cherry-mx-rubber-o-ri...

While this isn't exactly the same, the convention of appending "!" in scheme/racket to denote a function that mutates a value is helpful in my opinion. You don't absolutely need it, but reading through your code and easily identifying where your values can change is nice.