Multiple vulnerabilities released in NTP - <AUTHOR> http://support.ntp.org/bin/view/Main/SecurityNotice#Buffer_overflow_in_ctl_putdata <comment><USER2> PHK has been working on a rewrite of ntp sponsored by the Linux Foundation. He has posted a couple of entries about his progress so far: [http://phk.freebsd.dk/time/20140926.html](http://phk.freebsd.dk/time/20140926.html)

In the meantime Miroslav's chrony is a good alternative: [http://chrony.tuxfamily.org/](http://chrony.tuxfamily.org/)

If you are looking for the fixed version you can grab 4.2.8 from archive.ntp.org which is still responding to requests: [http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.8.tar.gz](http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.8.tar.gz)

<comment><USER3> systemd also has a minimalistic ntp client. It does not implement the full ntp spec but is sufficient for most desktop and server systems.

<comment><USER2> While the latter half of your comment is a matter of opinion/taste, the first half is categorically incorrect. systemd-timesync _is not a minimalistic ntp client,_ it is a minimalistic sntp client. But do not take my word for it, the authors made this clear in the announcement:

      > A new "systemd-timesyncd" daemon has been added for synchronizing
      > the system clock across the network. It implements an SNTP client.

I disagree that systemd-timesync is sufficient for most desktops and servers. We do not even need to go down the rabbit hole of discussing one's required stability/precision/accuracy to see a big problem with the "sufficiency" of systemd for most desktops/servers and the developers acknowledge it a couple sentences later in the announcement they "not bother with the full NTP complexity, focusing on querying time from one remote server and synchronizing the local clock to it." How do you detect falsetickers when you only have one sample? When they decided to ignore all the complexity they also chose to ignore clock drift. Maybe your dekstops/servers come with rubidium standards, but the rest of us have crappy crystals. I like that ntp/chrony decided to address clock drift...

</comment></comment></comment><comment><USER4> [http://webcache.googleusercontent.com/search?q=cache%3Asuppo...](http://webcache.googleusercontent.com/search?q=cache%3Asupport.ntp.org%2Fbin%2Fview%2FMain%2FSecurityNotice%23Buffer_overflow_in_ctl_putdata&oq=cache%3Asupport.ntp.org%2Fbin%2Fview%2FMain%2FSecurityNotice%23Buffer_overflow_in_ctl_putdata&aqs=chrome..69i57j69i58.798j0j4&sourceid=chrome&es_sm=0&ie=UTF-8)

</comment><comment><USER5> It is important to know how NTP works before you set it up. Several of the comments seem to be misguided. NTP is a peer-to-peer protocol, there are no such thing as an "NTP server" or an "NTP client".

NTP measures clock drift over a server group. It discovers enough about your topology to assign a statistical factor to each peer, so that a rogue or broken server can not bring down the whole group.

Known good time (which is what the stratum value is, a measure of distance to known good time) is then sprinkled in from several sources to drift the time in the direction of true time.

Exactly as you should have a number of secondary DNS servers in different AS, you should use several different time sources from different organizations. If you are bigger than a closet shop, you might as well put your own GPS receiver in there too when sparkfun sells them for $40, and enable authentication on it.

<comment><USER6> You wouldn't consider a server at stratum 0 and NTP server?

<comment><USER5> Dedicated ntp peers are often called servers. It's not strictly true in the client/server protocol architecture sense.

</comment></comment></comment><comment><USER7> NTP is one of those old school Internet protocols that was developed in "a more civilized age". The reference implementation "growed like Topsy" in an academic setting. So it's not surprising that it has serious vulnerabilities.

Many years ago OpenBSD threw up their hands and just decided to roll their own, named OpenNTPD. It's not nearly as full featured as the reference implementation, but it works fine for most people.

Edit: forgot to mention that OpenNTPD does privilege separation (don't know if reference implementation has added that yet). Which means that "executed with the privilege level of the ntpd process" isn't nearly as scary as when the process is running as root.

<comment><USER8> NTP's author, Eric Fair, is actually the son of the founder of Fair-Issac. Very smart cat, but this was all written so, so long ago it was bound to be exploitable sooner or later.

<comment><USER2> NTP's "author" \--where author is defined as author of the original RFC (958), every subsequent RFC (1305, 5905, etc) and reference implementation-- is Prof. David Mills. Prof. Mills is one of the unsung heros of the internet.

</comment></comment></comment><comment><USER9> Random non-trolling question by someone who is genuinely unfamiliar with the problem space: is it worthwhile rewriting these utilities in a language that avoids these sorts of problems? Is it because they're far more complicated than I realise and rewrites would create more problems that it solves? It is because until Rust is 1.0 there isn't a language that is suitable? Or am I missunderstanding the problem completely?

My reasoning comes from the vast majority of problems I notice being from the edge cases in managing memory, and so if I understand correctly there is a whole suite of languages that mostly remove these problems.

<comment><USER10> No, rewriting things in memory safe languages is absolutely something that should be done where it makes sense. There is no good reason to write things like ntpd in C anymore.

Anyone who says you'll just have a new set of similar issues is full of crap. You'll likely have issues, but ruling out memory corruption out the door is an indisputable win.

<comment><USER11> Well, there are still some good reasons to write things in C. For one it's standardized. Two it's ubiquitous.

I agree that projects should have a way to verify with 100% accuracy the memory safety of their code. One way to do that is to rewrite in another language.

Another way to do that is to use a static analyzer that lists out all unsafe operations in your codebase. Here's one [http://goto.ucsd.edu/csolve/](http://goto.ucsd.edu/csolve/). Adds an extra build step / precommit-hook but IMO the cost/benefit is much better than rewriting your project. After all, we can't just rewrite our code every time a new safe language comes out.

<comment><USER10> You don't seem to understand this problem space.

</comment></comment></comment></comment><comment><USER12> Do these vulnerabilities impact a local ntpd instance responsible only for local timekeeping? (In other words, does a compromised machine in pool.ntp.org pose a threat?)

<comment><USER13> There are 6 bugs that were announced.

#1 Weak default key in config_auth()

If you're only doing local timekeeping, and not using authentication (you'd know if you were) this doesn't apply. Basically the automatically generated key used for authentication (if you didn't specify one) was only 31 bits long and easily guessable.

#2 non-cryptographic random number generator with weak seed used by ntp-keygen to generate symmetric keys

Same as the above. If you're not using keyed sessions with remote hosts, this doesn't apply to you. Even if you are, the worst you're losing here is that someone could potentially mess with your clock.

#3 Buffer overflow in crypto_recv()

If you are using crypto (i.e. your ntp.conf file contains a line starting with "crypto pw"), you are potentially remotely exploitable to remote code execution. You probably do not have that configuration line set unless you know you put it there.

#4 Buffer overflow in ctl_putdata()

From the sound of the post on ntp.org, this is the scary one. "A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process." This makes it sound like everyone is exploitable. However, Redhat says "the ctl_putdata() flaw, by default, can only be exploited via local attackers". This makes me believe if you have your ntp.conf locked down using the 'restrict' lines you might not be vulnerable.

#5 Buffer overflow in configure()

This is the same as #4, ntp.org's advisory is vague enough that it sounds like everyone is vulnerable. Redhat is saying "the configure() flaw requires additional authentication to exploit." I do not know what this means.

#6 receive(): missing return on error

From their description, it's technically possible (but they haven't done it) to get ntpd into a weird state that is unlikely to be exploitable.

TL;DR: You're possibly vulnerable to #4 and #5 on a stock configuration. Redhat says no, ntp.org's advisory is vague enough that I'm not sure.

</comment></comment><comment><USER14> The ntpd daemon does not run as root. So, how is it able to change the time of the system? Does it use setuid, or caps, or something else?

I wonder because this would also affect what arbitrary code could be run as the ntp user.

<comment><USER15> It appears to use capabilities:

      $ ps u 561
      USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
      ntp        561  0.0  0.0   5856   780 ?        Ss   Jul14  22:37 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 103:107

      $ /sbin/getpcaps 561
      Capabilities for `561': = cap_net_bind_service,cap_sys_time+ep

</comment></comment><comment><USER16> Might want to check out OpenBSD's OpenNTPD:

[http://www.openntpd.org/](http://www.openntpd.org/)

<comment><USER17> I've talked to several developers about the state of NTP daemons and neither OpenNTPD nor DragonflyBSD's dntpd are suitable replacements. Neither of those support NTP Authentication nor do they have all of the required algorithms required for proper timekeeping.

<comment><USER18> >nor do they have all of the required algorithms required for proper timekeeping.

I hear something like that a lot, yet all my systems run openntpd and all of them are keeping proper time without issue. What exactly is so not proper about it, and which algorithm exactly does it need to be "proper"?

<comment><USER19> From the openntpd.org site at [http://www.openntpd.org/goals.html](http://www.openntpd.org/goals.html):

 _Reach a reasonable accuracy. We are not after the last microseconds._

Whereas NTP looks for maximum accuracy.

<comment><USER18> There's a big difference between "proper" and "more accurate than 99.999999999% of people care about" though. How many microseconds of accuracy do most people need? How many does openntpd provide and how many does the other ntpd provide? Claiming it isn't "proper" because in theory it may be 2 microseconds less accurate in some circumstances sounds like FUD.

</comment></comment></comment></comment></comment><comment><USER20> The site appears to be non-responsive, here is a cached version of the page: [https://webcache.googleusercontent.com/search?q=cache:jMcfip...](https://webcache.googleusercontent.com/search?q=cache:jMcfipOGXXwJ:support.ntp.org/bin/view/Main/SecurityNotice+&cd=1&hl=en&ct=clnk&gl=us)

</comment><comment><USER7> Theo de Raadt of OpenBSD weighs in on this issue:

[http://firstname.lastname@example.com/msg21729.html](http://www.mail- email@example.com/msg21729.html)

</comment><comment><USER21> This is interesting timing, I was just in the freenode #linux channel yesterday asking about security issues with NTP. I got told it was a non-issue and that I was "tilting at windmills". I have been using chronyd in Alpine linux to good effect so far, but have really been wondering how bad it would be if I just turned it all off.

<comment><USER22> having a host clock that is out of sync can be incredibly troublesome, especially if you have more than one system.

<comment><USER23> Especially if your distributed database relies on clocks, as some do.

<comment><USER24> Eww. What does that?

Vector clocks? Sure. UTC clocks? Not a chance in hell I'd ever trust them for a reconciliation protocol. I've spent way too much time around the internals of hypervisors, and seeing how various OSes (and versions of them) do and don't keep time well in virtualized environments gives me zero confidence. The fact that any two given cloud VMs agree on the time within 500ms is a testament to the sheer bullheaded determination of their administrators.

Simply, you cannot trust timestamps between two machines to determine ordering. If you do, you _will_ have a bad time sooner or later (so to speak).

<comment><USER25> AFAIK only spanner uses real time as a core primitive. They don't use ntp ;-)

Monotonic sequence numbers loosely based on real time are common, since you can correlate the sequence number back to an actual time to look at logs, etc. Time skew wouldn't break the protocol, just make it annoying to correlate after the fact.

And of course any leasing system uses bounded clock skew rate between hosts, but NOT bounded absolute skew.

</comment></comment></comment></comment></comment><comment><USER26> All of the buffer overflows are on the stack, right? Shouldn't the default stack protector that most compilers today enable should stop that from being exploitable for remote code execution?

I'm just trying to estimate the likelihood that anyone was hacked through this vulnerability. Even with stack protection the vulnerability could be used to crash ntp, so upgrading is a very good idea still.

<comment><USER27> There are ways of bypassing stack canaries, depending on the specific application and environment. No exploitation mitigation is ever fool-proof.

Also, in many cases applications will be distributed or have Makefiles without enabling stack canaries or sometimes even DEP and ASLR.

<comment><USER26> >There are ways of bypassing stack canaries, depending on the specific application and environment.

Bypassing a stack canary generally requires a separate memory disclosure vulnerability if I remember right. (Or an interesting local variable in the same function as the buffer like a function pointer, but I think compilers now are smart enough to try to arrange buffers to be the last thing on the stack before the canary.) It wouldn't be surprising if one existed, but I don't think any were publicly disclosed now.

I guess what I'm asking is: 1) Are there any public exploits that get remote code execution against NTP on modern systems (Should we expect that the average MITM is popping shells with this already on most systems?), and 2) do all modern distributions (like say Debian) containing NTP have the standard default mitigations (DEP, stack canaries, etc) enabled on NTP, or why not?

</comment></comment></comment><comment><USER28> The best solution is not to use ntp anyway. It's an unencrypted, unauthenticated protocol vulnerable to Man in the Middle attacks. There was a pretty neat attack presented at BH Europe circumventing HSTS with a MitM- attack on NTP.

Better just replace it with tlsdate.

<comment><USER2> ntp network traffic can be authenticated with symetric keys or autokey currently, and with NTS in the future. Many national labs support authenticated time for free and even more provide authenticated ntp for a fee.[1] Moreover if you care about time you can use a cheap GPS+PPS[2] as a reference or splurge and get a CDMA card. Your "replace it with tlsdate" solution makes little sense; at some point you need NTP or PTP to acquire and synch to UTC.

Why would anyone need encrypted time synch? I do not understand the privacy implications, UTC is not a secret.

[1]: For example: [http://www.nist.gov/pml/div688/grp40/auth- ntp.cfm](http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm) or [https://www.nrc- cnrc.gc.ca/eng/solutions/advisory/calibratio...](https://www.nrc- cnrc.gc.ca/eng/solutions/advisory/calibration/time_frequency.html#authenticated)

[2]: My sure gps puck cost $40. It works with the antenna sitting on the window ledge inside my house.

<comment><USER29> You need encrypted time sync when you don't have a local trusted source, and to reduce your susceptibility to to pseudo MITM attacks (though, having just said that, you're right - UTC isn't a secret, so an attacker could just use that. However, and I'm not sure the answer, the key may be in how much information is leaked to the NTP server on current clock drift state. That being said, I'm fairly sure Kerberos etc don't require millisecond level time sync...)

<comment><USER2> You are confusing authentication and encryption. Authenticated time protects against MITM attacks. You can obtain authenticated time synch from many national labs, such as NIST[1] or CRC[2].

I do not understand the need for confidentiality.

[1]: [http://www.nist.gov/pml/div688/grp40/auth- ntp.cfm](http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm)

[2]: [https://www.nrc- cnrc.gc.ca/eng/solutions/advisory/calibratio...](https://www.nrc- cnrc.gc.ca/eng/solutions/advisory/calibration/time_frequency.html#authenticated)

<comment><USER29> Well, my thought was that you might be able to determine local clock drift by snooping. But as then mentioned, that's of near zero use, I suspect (as anything that uses time sync for authentication or otherwise is not likely to be that tightly bound to accuracy).

</comment></comment></comment></comment></comment><comment><USER30> Naturally DJB recognized and fixed the security problems of NTP, way back in 1998: [http://cr.yp.to/clockspeed.html](http://cr.yp.to/clockspeed.html)

 _Plus ça change, plus c 'est la même chose..._

</comment><comment><USER31> _A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process._

Geez, in a time sync program? Nothing is safe anymore.

<comment><USER32> ntpd is a, uh, rather large time sync program.

<comment><USER33> Indeed. PHK noted that it's on the order of 100,000 lines of code. That's a staggering amount for something that queries a remote server and steers your clock.

<comment><USER34> 100,000 lines of C is certainly unnecessary for the most common usage of ntpd, but it is far from staggering considering ntpd's full scope as a portable client, server, and peer-to-peer node attempting high precision synchronization on heterogeneous hardware across the globe.

It doesn't just "query a remote server and steer your clock", and "steer your clock" is a lot more complicated than it sounds when you're trying to achieve such precision.

<comment><USER35> Actually, you're wrong.

Most of that source code is there for different and wrong reasons.

It doesn't take much source code to steer your clock precisly, we are talking less than 100 lines.

What takes up space is all the "extras" and "nice to haves".

<comment><USER34> I don't think I am, and you haven't given me any reason to believe I am.

Why don't you list some of those "extras" and "nice to haves"? Some of them are probably absolutely critical to my services. All of them are probably critical to somebody's.

I don't think you're understanding that I'm not in any way disputing that we need something orders of magnitude smaller for the most common case of a simple desktop or server keeping an approximately accurate clock.

If your response to me talks about just steering a clock, _you are not responding to me_.

<comment><USER35> Apologies for being a bit terse, but I've got stuff to do, including buying X-mas presents for my family :-)

I've already written about most of this in my little "time-blog" related to this project: [http://phk.freebsd.dk/time/index.html](http://phk.freebsd.dk/time/index.html)

Feel free to ask any questions not already answered there.

Right now ntimed is less than 4KLOC and while it isn't complete yet, it does contain precision timekeeping, a data collector to record simulation input, a simulator to chew on those tracefiles and the real-time clock-steering code.

It really isn't rocket size.

OpenBSD's NTP implementation is similar size, but they sort of threw their hands op on smart clock-steering, opting instead for "KISS" from a security point of view.

The main reason I didn't start from OpenBSD's NTP implementation is that it is not aimed at being part of a larger family of time-keeping programs, like I intend to deliver, so it wouldn't save me any time in the end.

(I'll be proud if OpenBSD adopts my ntimed, but I'll fully understand and accept if they do not.)

Adding support for being a NTP server is mostly a matter of writing code to defend against packet storms (See: [http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-L...](http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-Link_and_Poul- Henning_Kamp))

Adding refclocks should never happen in the "main" process, but rather they should be separate processes, suitably sandboxed and interfaced via a good simple API. (I have radical plans for this, which will allow refclocks to be implemented in PL/1, REXX or INTERCAL if that's how you roll :-)

But right here, right now, my focus is to get the vast majority of all machines away from running NTPD, purely as a matter of security and robustness, while improving their timekeeping at the same time.

If ntimed-client ever grows above 10KLOC, I've failed that goal.

First preview release of the source code will happen this weekend.

<comment><USER34> You're defending a lot of stuff I didn't attack. Almost everything you're doing sounds good to me, and I have no idea why you would think otherwise.

The only point I made was that 100,000 lines is not staggering for all of the functionality ntpd encompasses, which goes way beyond just "query and steer".

I didn't say a typical NTP client should be 100,000 lines. 10,000 lines sounds far, far too large to me, in fact, for the 80-90% case.

<comment><USER35> First, all functionality included, NTPD is presently 363.000 lines of .c and .h files.

Second, the 100.000 is my guesstimate of what is necessary for "core functionality" and I think that is still a pretty staggering size for what that "core functionality" is.

There is a lot of ancient infrastructure which complicates otherwise very simple tasks, some design-choices, perfectly valid in 1980 should have been revisited no later than 2000, far too much duplicated functionality, because people didn't know or couldn't get the other copy working etc.

My initial plan was to do a serious rebuild of the existing code, in deference to Prof. Dave Mills and NTPDs long legacy (probably one the longest running open source projects!), but in the end I had to admit that such a strategy would be inefficient on any relevant metric.

I think I could write a bare-bone NTP client in well less than 1000 lines, but it wouldn't be very user-friendly, net-friendly or clock-friendly.

Usability in particular soaks up space, but we're not in 1980 any more, so there is no excuse for stuff like this any more:

       #define  DEFPROPDELAY    0x00624dd3 /* 0.0015 seconds, 1.5 ms */

But doing this takes some code:

      critter phk> ./ntimed-client -p pll_std_capture_time
      Parameter:
            pll_std_capture_time
      Minimum:
            2.000e+01
      Maximum:
            1.000e+06
      Default:
            3.000e+02
      Description:
            Capture time before stiffning PLL.

            After this many seconds, the PLL will start to stiffen the P
            and I terms to gain noise immunity.  Decreasing risks that
            initial frequency capture is not finished, which will increase
            the offset-excursion.  Increasing just delays this stiffning.

      Failure: Stopping after parameter query.

I don't have a target size for the program, but 5-10.000 lines for a robust, reliable, secure and usable time sync client sounds reasonable to me.

... and that will still be less than 3% of the current NTPD.

<comment><USER34> I really have no interest in this. You're being incredibly defensive and looking for reasons to argue with someone you don't fundamentally disagree with about trivial crap. For someone who professes to be so busy, that's very strange.

<comment><USER36> I would guess that PHK, being PHK, is just being thorough rather than defensive. After all, if you can avoid a lot of back and forth, you're saving everybody time. Of all people here, he's definitely one of the ones worth giving the benefit of the doubt.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER37> "The connection was reset" something weird going on. Lots of HN articles is been removed by some one. Many sites I visited today, is just down.

</comment><comment><USER38> Do these apply to ntpd in OSX?

<comment><USER39> I haven't verified the vulnerability locally, but as of OS X 10.10.1 (14B25), ntpd at least identifies itself as version 4.2.6, which is affected.

</comment></comment><comment><USER40> Bad timing for such a vulnerability with the holidays and everything. I don't have time for that.

</comment><comment><USER41> Just give it a few weeks and I'm sure the systemd developers will make their own "newer and better" ntpd.

<comment><USER42> You're late to the party [https://wiki.archlinux.org/index.php/systemd- timesyncd](https://wiki.archlinux.org/index.php/systemd-timesyncd) ;)</comment></comment>


Pitch your idea to executives flying on Virgin - <AUTHOR> http://www.virgin.com/entrepreneur/pitchtv/richard-branson-introduces-pitchtv/

<comment><USER2> as a business traveler, would you consider it a nuisance or a value-add?

I see Branson absorbing significant value from the idea-flow

</comment><comment><USER3> the website is wildly out of date... are they still doing it?

<comment><USER4> according to a tweet from July, they aren't accepting any more pitches. <http://twitter.com/virginpitchtv></comment></comment>


What Do VCs Read Online? - <AUTHOR>

I am wondering where do VCs get their information from online sources (beyond TC..) <comment><USER2> TC is sort of where you read news after it was news, or if it's just a press release sort of thing. Not a terribly good source of information; few hold it in high regard.

You might be surprised how many VC's read Hacker News. Product Hunt is also very popular.

</comment><comment><USER3> Try to find out what people are sharing on Twitter. For example: [http://nuzzel.com/abrams/angellist](http://nuzzel.com/abrams/angellist)</comment>


People with high speed Internet vote democrat - <AUTHOR> https://plus.google.com/u/0/114476892281222708332/posts/cVpwkmwW9M9

<comment><AUTHOR> If you overlay a US map of broadband access on top of counties that voted democrat, the areas with highest broadband vote democrat with slower areas voting republican. It's a crude analysis but interesting.</comment>


E-field-based 3D gesture-recognition chip - <AUTHOR> https://www.edn.com/microchip-elevates-hmi-design-with-worlds-first-e-field-based-3d-gesture-recognition-chip/ <comment><AUTHOR> Why has this not taken off? Off-the-surface gestures seem like they'd really enrich smartphone experience. I don't get why this low power proven tech has not been incorporated into phones. It's already 8 years old!

<comment><USER2> Why do you think it's not in use? Microchip calls it a "capacitive touch sensor" IC on their website. Plenty of phones have that.

<comment><AUTHOR> Really? This one is a 3D sensor. Off-the-screen gestures. Have you seen people making gestures above the surface of their phones?

I haven't seen that. Why hasn't it happened yet?

 _edit_ : Anywho, let's check the Microchip website. They don't call it what you said. There's no capacitive touch on its page, just the title. It's all 3D e-field. I think you must have got the wrong chip. Where did you see it?

[https://www.microchip.com/wwwproducts/en/mgc3130](https://www.microchip.com/wwwproducts/en/mgc3130)

</comment></comment></comment><comment><USER3> Hope to see an wristband which recognizes hand gestures soon. Together with smartphone head tracking it could open the window to useful everyday AR.

</comment><comment><USER4> Article is from 2012.</comment>


Modify new Gmail interface to be more like classic Gmail - <AUTHOR> https://www.dedoimedo.com/computers/gmail-new-looks-change.html <comment><USER2> Is there really much more innovation to be had with email ux? Perhaps I'm getting old, but I'm getting frustrated with having to learn new interfaces that don't improve my experience.

Each new version of Android or iOS changes the UI in small but useless ways. I mean, why change the way the clock app works in Android so frequently.

It's not worth the cognitive overhead of relearning how to do simple. What is driving this? Is it that a bunch of engineers have what are essentially bullshit jobs, or do companies feel they need to keep fresh or die?

My parents are about to hit 70, and these types of changes for the elderly are even more stressful. Why should they need to relearn how to use an email interface?

We need software with super long term support release that just get bug fixed for ~20 years. Redesigning the UI for essential every day things is wasting time. Plus, unless you are 18 years old the even worse Snapchat style UI antipatterns create a huge impediment to doing things that should be dead simple.

<comment><USER3> > Each new version of Android or iOS changes the UI in small but useless ways. > I mean, why change the way the clock app works in Android so frequently.

I thought the same, till I thought about it from a notch perspective. They moved it so that you could fit the system icons with a large notch like the Pixel 3 XL has. The clock was moved on the other side simply to make room for this.

<comment><USER3> Oh, I thought you were talking about the clock in the system tray. Sorry, I completely agree with the clock app. I would wake up every morning and the UI would be different. It definitely drove me insane because I would forget how to snooze while I am groggy in the morning and end up sleeping in longer than expected because I swiped the wrong way or whatever.

</comment></comment></comment><comment><USER4> I'm not particularly looking forward to the day I'm forced into the new interface. It's slow as hell on Firefox and is continually dropping keyboard shortcut events unless I type each. one. slowly. and. deliberately.

<comment><USER5> Yeah it takes like 20 seconds to load on Firefox.. Whats they deal with that; Is that on purpose to force people to use chrome?? I'd rather drop gmail, but I'll need to change my email for like 100 accounts which will be a massive pain...

Actually is there any way around that?

<comment><USER6> Enable forwarding to the new address. Update email contacts and accounts as needed.

Be sure to check that forwarding exists on your new provider, just in case you'll have to do the same when switching again.

Better yet: buy your own domain and use a service that allows you to use it.

</comment></comment></comment><comment><USER7> I'm just using Gmail in basic HTML mode now. It's blisteringly fast and there's no extra nonsense.

<comment><USER8> The problem is Gmail forces you to switch to the new interface. It doesn't stick with the HTML version, which, no surprise, is superior to the new dumpster fire.

<comment><USER9> Try the Basic HTML view linked at the bottom of [https://support.google.com/mail/answer/15049](https://support.google.com/mail/answer/15049).

It's is web 1.0, but it sticks, and it is fast.

<comment><USER8> I have tried that, but Gmail forces me back to use the new interface.

<comment><USER7> You can bookmark the html version. Also whenever main gmail is loading, there is a link to load the html version in the corner.

</comment></comment></comment></comment></comment><comment><USER10> The font was probably the most jarring thing to me - it really is _much_ less readable than the old one.

<comment><USER11> Google's started to use Product Sans in Google Maps on Android too, and it's just as bad there.

</comment></comment><comment><AUTHOR> I use the basic HTML interface, so I almost stopped reading at _" The new interface loads more slowly than before (especially in Firefox)"_.

My takeaway: nice info for helping friends & family, but I'm staying on basic HTML.

</comment><comment><USER12> Just move to fastmail. I mean yes, the gmail load screen sucks, but the Gmail compose window is awfully slow too.

Fastmail does imap push in an ios compatible way, and their web client is fast and works.

Fastmail's import process for Gmail is stupid - it asks you questions it should already know the answers to - but it worked and ported my 5GB mailbox a week ago.

<comment><USER13> The speed issue is even more pervasive -- compose, but also labels (if you use L to label emails a lot, you have noticed it).

Two questions, if you do not mind --

(1) Does FastMail offer threaded email conversations? I cannot stand the left/right pane display of email UIs like Outlook (or Apple Mail).

(2) Does FastMail offer labels and filters that come close to those in Google Mail?

</comment></comment><comment><USER14> I am another disappointed by the new Gmail UI. A quick list off the top of my head: Compose and pause buttons are huge (and I never use Pause), side bar got much larger, new font is less readable, "Compact" density option is still less dense than previous design, notifications are at the bottom now, and it's slow.

I've disabled: Smart replies, nudges, hover actions, Smart compose, icon buttons, multiple inboxes, etc.

I just want a simple clean interface. I'm going to revert the font through the details in this article and then just hope Google UI teams start to come to their senses. So many broken UI's in their products in the last year.

</comment><comment><USER15> After the new interface was brought out, I found that the most jarring thing was how the left-hand-side menu collapsed down left to a set of meaningless icons, then when you hovered over it, it expanded right to cover important details of the actual emails.

Either I disabled it using some obscure setting or Google fixed it within a few days. I wonder if they knew people weren't going to like the update, and intentionally added temporary extra annoyances with the goal of acclimatizing users to the smaller and more profitable annoyance of the "AI" autocomplete and autorespond. The cynicism comes from having been a Facebook user.

EDIT: typos

<comment><USER16> I immediately disabled the "smart completion". It was wrong 100% of the time so far, and it's just going to ruin my train of thought, or worse, train me to say what it thinks I should say.

</comment></comment><comment><USER17> Can someone make the opposite and make it more like Google Inbox?

</comment><comment><USER18> 99% of the complaints I've heard about the new Gmail haven't been about the interface, they've been about the speed.

</comment><comment><USER19> I know it is old-fashioned, but you could always set up a mail client like Thunderbird to talk to Gmail and keep a consistent UI.

</comment><comment><USER8> This new interface finally pushed me to use FastMail. The interface is way better, and I can use my domain name. No more Gmail.

</comment><comment><USER20> All I want is one line per email interface. I refuse to use an entire screen width for the gmail window. The classic had a "comfy" (or whatever it was called) interface that did that. If the new ux can be forced to do resizing of the columns I would be happy again with gmail.

</comment><comment><USER21> I dislike everything Google. Not only for this reason but for privacy reasons. So I confront this by using firefox klar and duckduckgo.com and gmx.com for my user combo.

</comment><comment><USER22> Basic HTML mode is the way to go.</comment>


Mediasmart: How to Handle a Reporter by a Reporter - <AUTHOR> http://www.amazon.com/Mediasmart-How-Handle-Reporter/dp/0964042908

<comment><AUTHOR> An amazingly useful book that reveals how mainstream media (especially, but not only, TV) find sources, and how you (the source) can control reporting about your activities.</comment>


Facebook acquires sport data firm SportStream - <AUTHOR> http://www.bbc.co.uk/news/technology-25426238

<comment> pre-show-mac How creepy of faceblock to put up a mural made of tiles of their users pictures! As if anyone would agree to that. What bunch of f __kin ' creepos.

edit: how many of those pix are from underage people, and/or people that have committed suicide from being hassled on faceblock?</comment>


How to Write a Git Commit Message - <AUTHOR> http://chris.beams.io/posts/git-commit/ <comment><USER2> The biggest problem with commit messages: They lie.

The main reason for this is that most people tend put more than one atomic change into a single commit, but in the message they often only mention the "main change" which they introduced with the commit. This in turn makes it much harder to find out which commit introduced a given problem into the code base since people will usually read the (incomplete) message of a given commit and think "the problem can't be here because this commit only did X" while it actually did Y & Z as well. So, personally, I think we could as well abandon writing commit messages entirely and instead make sure that individual changes are small enough so that we can figure out what happened by looking at the actual code instead.

As an example, if you look at individual commits in the Django project (such as this one: [https://github.com/django/django/commit/e7e8d30cae9457339eb4...](https://github.com/django/django/commit/e7e8d30cae9457339eb49ae8584e82ff0a038e99)), it is often much easier to figure out what happened by looking at the file diff than the commit message.

A tool that could summarize changes in source code using advanced (semantic) diffing instead of line-by-line diffs would make this much easier of course.

<comment><USER3> With magit, it's easy to only stage individual 'hunks' so that you can have only the relevant parts of a file staged. And so this problem goes away.

I also imagine it's easy to do this in fugitive as well.

It's probably also possible on the cli, but I imagine that would be too 'hard' or time consuming, hence you will probably start to be lazy about doing it correctly.

<comment><USER4> >It's probably also possible on the cli, but I imagine that would be too 'hard' or time consuming, hence you will probably start to be lazy about doing it correctly.

I do it all the time, you just use `git add -p` and it steps through hunks letting you stage them or not. As long as you don't make too many changes without committing, it's not particularly tedious.

<comment><USER5> This was the 'killer app' that compelled me to switch to Git from Subversion back in the day, rather than anything else about Git intrinsically. The ability to organise my commits logically rather than temporally (i.e. not just as a stupid log of change over time) was like night and day.

<comment><USER6> > ability to organise my commits logically rather than temporally

I'm just getting started with Git; how do you do that? I googled it but nothing jumped out at me.

<comment><USER7> He referred to what the GP said - use "git add -p". Here's some introduction (I haven't watched it myself and can't comment on the quality):

[http://johnkary.net/blog/git-add-p-the-most-powerful-git- fea...](http://johnkary.net/blog/git-add-p-the-most-powerful-git-feature- youre-not-using-yet/)

</comment></comment></comment></comment></comment></comment><comment><USER8> Out of all common advice on Git commit messages always using the imperative mood in the title I find the hardest to agree with. Describing your own actions as a committer in the imperative may sound strange, true, but there is the worse problem of making less obvious the distinction between the actions of the system and those of the committer.

In my own projects I use the imperative when describing the actions the system should perform ("Don't warn user about missing cache directory") but use the indicative mood when describing my own actions ("Removed unnecessary cache directory warning"). I've noticed that some projects use the imperative for both cases and I suspect this introduces a degree of cognitive overhead to scanning the commit log. One solution to this problem would be to never "address the system" in the commit title but I find that that is often the shortest and the most expressive way to describe an update.

<comment><USER9> I think GitHub has broken us a lot here.

Commits, when extracted from the repository, need to stand on their own. Example: sending a commit over email. Then you look at a commit message and you _do_ ask "What does this commit do?" The commit doesn't "removed unnecessary things" because that just sounds wrong—the commit didn't _already_ do things before it existed.

The weirdness comes from describing what the author already _did_ to even create the commit versus what someone encounters when they read the commit for the first time. Your historical actions don't matter in writing results, only future readers matter for what they discover the patch _will_ change.

<comment><USER10> Agreed. GitHub has really done a lot to harm the quality of commits. Their tools emphasize looking at and commenting on the total diff of the patch set rather than inspecting each commit on its own. I tried commenting on the patches themselves once only to realize that the pull request page didn't show them and they were hard for the author to find. Unfortunately, it doesn't seem that GitHub is willing to change their code review tools since even Linus Torvalds complained about them and nothing important was changed.

<comment><USER11> Luckily, since GitHub has a pretty extensive API, this leaves the way open for third-party code review solutions like [https://reviewable.io](https://reviewable.io) (disclosure: I built it). But yeah, considering how long it took them just to put in a split view, I wouldn't expect a whole lot of improvements in the foreseeable future...

</comment></comment></comment></comment><comment><USER12> Does the majority read commit messages as "If applied, this commit will..."?

I always treated log messages as a history of events, i.e. describing what had happened in the past - this commit "fixed" something, and this one "changed" something, "refactored", "implemented", etc.

<comment><USER9> A commit object is a container talking about itself. You don't talk about your present state in the past tense.

<comment><USER13> A commit object is a container of changes. A commit message is a label placed on that container by whoever packed it. It's not the container talking about itself – it's a programmer labeling something for other programmers to read (in the future) about something they have already done.

<comment><USER14> That would be the egocentric view, instead of letting the commit stand on its own.

</comment></comment></comment></comment><comment><USER15> Magit for Emacs helps you maintain some of these standards if you enable flyspell for git-commit-mode.

And obviously Emacs is my editor of choice for everything, git commits included.

<comment><USER10> +1 for Magit and Emacs. They are my not-so-secret weapons.

</comment></comment><comment><USER16> We advocate also using hashtags and URLs in the commit message body.

Our hashtags correspond to specific areas such as #analytics, #localization, #api. These hashtags are easily searchable by the respective teams, and we also use simple shell scripts that categorize by tag, e.g. "List all the changes related to #analytics".

Our URLs link to the corresponding tasks in Asana, Jira, etc., and also to any relevant background information such as RFCs, ISO standards, NIST docs, etc.

<comment><USER17> Saw this blog last week : [http://ericjmritz.name/2015/05/27/my-global-git- commit-templ...](http://ericjmritz.name/2015/05/27/my-global-git-commit- template/)

He uses a template with a few metadata, and tags too. In an older entry he mentions using a special WIP tag for successive sequences of iterative changes toward a fix too.

<comment><USER14> Isn't WIP what branches are for?

<comment><USER17> I guess I don't branch enough then.

</comment></comment></comment></comment><comment><USER18> >3\. Capitalize the subject line

>4\. Do not end the subject line with a period

>5\. Use the imperative mood in the subject line

I can't help but feel that these three "rules" should be removed and placed in a separate list of style guidelines since "breaking" them is hardly going to make your commit message unreadable.

E.g.:

        5ba3db6 fixed failing CompositePropertySourceTests.

would still good enough in my book. I think _consistency_ is actually more important than following those three prescriptions specifically. It only becomes an issue if you capitalize some subjects but not others, alternate between imperatives and past participles, or use different punctuation styles.

</comment><comment><USER19> "Fix failing $test" and "Add tests" seems like a commit message anti-pattern. A failing test likely has its failure rooted in an actual problem that you could be describing instead, and a commit message simply stating that you added "multiple tests" lacks a rationale for each and every test added.

</comment><comment><USER20> A commit message should answer the question "why?".

In the article they ask "Which would you rather read?"

I would prefer to read the first commit message they offer as an example:

"Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle downstream effects, breaking unrelated tests. The test method is still useful, but should only be run on a manual basis to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build."

That is informative and gives me the information that I need. It answers the question "why?". And yet, this commit message is held up for criticism. And then, this is given as a recent example:

"Rework @PropertySource early parsing logic"

I have no idea what happened in that commit. And this commit does not answer the question of "why?".

I disagree with this entire article. The examples of "bad" commits are the one's that I would want my co-workers to write. The example of "good" commits are the kind that would make me angry with my co-workers.

Verbose commit messages are not useful because they are verbose, but a commit message should answer the question "why". Commit messages that answer the question "why" tend to be a bit longer than commit messages that fail to answer that question. I would much rather read a verbose message that answers the question of "why?" than I would read a short message that fails to answer that question.

<comment><USER21> Agreed -- when I read the article, I found the first set of commits more valuable than the second. Having short commits is better than long commits, but not at the expense of information. I don't need commits that use the words "updated, fixed, added" \-- if I'm looking at `blame` I know something was updated/fixed/added. What matters is how something was changed, and sometimes why it was changed.

Write commits that help your coworkers figure out why the code looks the way it does. If you're writing "update FooBarFactory to fix Bug4" you're essentially wasting my time by using git to narrate the obvious.

</comment></comment><comment><USER22> Again, recommending the angular style: [https://github.com/angular/angular.js/blob/master/CONTRIBUTI...](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit- message-format)

As (IMHO) the most important thing is where (out of many modules) is the change and of which kind (fix? a new feature? refactoring? only some docs?).

</comment><comment><USER23> Most of those rules are good. But don't lose focus on why you are writing commit messages in the first place which is to help some poor programmer many years from now to track down a bug in the code you wrote.

E.g His fourth rule to great commit messages is "Do not end the subject line with a period" But if you think it matters if there is a period at the end of the subject line or not, then you might have a bit of an anal retentive streak. :) Keeping your opening brace placements and indentation consistent, that's important because code is easier to read if it is formatted consistently. So some details matter and some details do not. Periods at the end of subject lines in commit messages is of the latter category.

</comment><comment><USER24> The page was very slow to load for me. Here's a mirror in case it goes down completely: [https://archive.is/LGRwO](https://archive.is/LGRwO)

</comment><comment><USER25> I have some problem with this:

> Use the imperative mood in the subject line

Sometimes, you don't have or don't want to link to a bug tracker bug. So it gets unpractical to write something like "fix the window that didn't close at the click of the button". It would be much better to write "Fix: button click did not close the window". This is even more true if you _have_ to write commits in a latin language.

I guess the bottom rule is synthesis and assertiveness should be only considered as a preferred method, not an hard rule.

<comment><USER26> > So it gets unpractical to write something like "fix the window that didn't > close at the click of the button".

Imperative style normally produces more direct messages than that; talk about how it behaves now, not how it used to:

"Close window when button clicked"

Or, assuming "button" here means "close button":

"Close window when user clicks close button"

<comment><USER27> Yeah, plus, the fact that you fix something is the "why" part of your commit message, it should go in the body. The result could look like this :

> Reduce overlaying div element width > > This caused a bug on some devices : > the div would overlay the close button, causing it to be unreachable.

I think that commit message that begin with "fix" are often not very good. Basically, you're saying "It was broken, this commit fixes it", not what was broken nor how your commit is _supposed_ to fix it (yeah because sometimes, people think they are fixing something and actually create another bug in another part of the thing).

<comment><USER25> Interesting, I'll think about that.

</comment></comment></comment></comment><comment><USER28> In the past few teams I've led, the requirement was to include a JIRA ticket number in the commit message. With tools like Fisheye, you can click from the commit message to the JIRA and get much more context about the particulars of the commit. It worked exceedingly well. The point is that there is only so much context you can put into a commit message. Sometimes the context lives outside the system and good tools support like Atlassian's suite makes life easier.

<comment><USER29> A lot of people do something similar on GitHub. If you're going to do this, please include the issue subject in the commit message somewhere. "Fixes #135" is absolutely meaningless outside the context of whatever tool. And it absolutely falls apart if the project lives long enough to change issue trackers.

<comment><USER30> Much agreed. "Fixes #123" makes sense for _pull request_ messages, but the commit messages should be verbose!

</comment></comment></comment><comment><USER31> When you work on a team that requires code reviews (pull requests) before every check-in, the "body" portion of the commit does not really make sense as the developer pretty much has to include that information in the code review description either way.

Most teams automatically put a link to the corresponding code review in the commit message/body.

<comment><USER32> I'd still prefer a body with a good commit description, since review descriptions are not attached to the history.

I've been thinking about this a little recently, the conversations that determine the direction of a product are not part of the history, if a repository is shared there's no way to see that information without going through emails, or going through issues on GitHub or Bitbucket or whatever else.

<comment><USER31> Is this something we can change though?

As you mentioned, these conversations happen everywhere including offline meetings and hallway chats.

</comment></comment></comment><comment><USER33> I like to point people to the Linux kernel `git log`[1] when talking about the value of good commit messages.

[1]: [https://github.com/torvalds/linux/commits/master](https://github.com/torvalds/linux/commits/master)

</comment><comment><USER34> I thought for sure it would be about this recently announced project, which also cited Tim Pope: [https://github.com/m1foley/fit- commit#readme](https://github.com/m1foley/fit-commit#readme)

</comment><comment><USER35> I recently started working on a tool that checks for this and more : [https://github.com/jorisroovers/gitlint](https://github.com/jorisroovers/gitlint)

</comment><comment><USER36> What I want to know is how to write good commit messages when you're first building your _thing_. Most of your code is unwritten and what is written is constantly changed to improve the interface(s).

</comment><comment><USER37> > and doing the right stuff with git when you rename one

What is he referring to?

</comment><comment><USER38> I have to disagree on "Capitalize the subject line". If you're using lower case consistently, it's an unnecessary stroke of the shift key.

<comment><USER39> Commit messages sometimes need to be longer to explain something. When that happens, it's nice for the subject to be the first sentence (possibly with the rest on another line).

      Don't warn the user about foo.

      The foo warning is superfluous because ...

> it's an unnecessary stroke of the shift key

This is not a good reason to argue for a style convention. The effort or time of pressing "shift+letter" is no greater than simply pressing "letter" for all experienced typists since they are pressed simultaneously and the decision to capitalize a letter and execute the necessary keypress is completely automatic and fluid. If we were discussing rarely-used symbols and keystrokes then the analysis might be different.

There is great value in following the language's style convention since its readers are familiar with that convention. Upper case denotes the beginning of a sentence. When you scan a series of lines beginning in upper case, there's a visual cue that they're each their own unit, as opposed to (for example) the wrapping of a previous line.

      Don't warn in case foo
      Update bar dependency
      Warn user when baz

These scan better to me as a series of three independent thoughts than the equivalent in lower case, which seems like a poorly written haiku:

      don't warn in case foo
      update bar dependency
      warn user when baz

Personal preference might differ, but my opinion based on seeing many variations is that programming texts such as documentation, commit messages, etc., are most readable when they follow the syntax and style of regular English text, to leverage all of the standard cues that the reader is familiar with. Readability usually suffers when one breaks from convention.

Lastly, following regular conventions gives you the advantage that you can copy/paste text across various scenarios without having to change it. Need to reference a commit message in an email? Well, just copy it in. No need to mess with the capitalization. All things considered I see no good reason to begin documentation or commit messages in lower case given the overwhelming conventions to the contrary that exist in our language.</comment></comment>


Why do so few humans kill themselves? - <AUTHOR> https://theviewfromhellyes.wordpress.com/2016/06/07/patch-7-822-an-experimental-design-puzzle/ <comment><USER4> While interesting, this article seems to ignore the possibility that most people simply have a very strong desire to live. It assumes that if someone is suffering, and death would end that suffering, then suicide makes sense, and something weird must be going on to make people keep going.

But this really doesn't make sense. The entire concept of suffering exists merely to keep us alive. We experience pain and despair and sadness not because it's some inherent part of being conscious, but because those sensations help us to avoid things which are detrimental to survival. When push comes to shove, the drive to survive is what's fundamental, and that will (usually) override the desire to avoid suffering.

As intelligent, conscious beings, we have the capability to understand when survival is no longer possible, making suffering a waste. Thus we can, sometimes, override our desire to live in the face of terminal illness. But what's weird is not the fact that we don't constantly kill ourselves at the first sign of trouble, what's weird is the fact that we _do_ sometimes kill ourselves when things look completely hopeless. You might as well _try_ to stay alive, after all.

<comment><USER5> In addition to a desire to live, not everyone views suffering as the worst possible thing.

If I had to be in serious pain every day but could keep doing many things I would rather keep living with the pain. The loss in experience is worse than any level of pain.

For the obvious counterpoint: I say that from experience not naivete. I've had a nerve in my hand accidentally sliced lengthwise (for a significant length) by a surgeon. The pain was so excruciating they had to put me under before I had a heart attack (heart rate+blood pressure both went off the charts, 290bpm)

However, before that happened I was much more interested in what was going on and how unique this level of pain was. It was fascinating. Prior to that I didn't really know how much pain it was possible to feel.

Anyway the point is, not everyone is afraid of pain and suffering. Especially not to the point that suicide would even be considered.

<comment><USER6> > If I had to be in serious pain every day but could keep doing many things I > would rather keep living with the pain.

Scratch that: <comment>No, you (most probably) wouldn't.<comment>

EDIT: this post is about severe chronic pain. Think cancer, or a serious toothache which lasts for years. And it's _not_ meant to discuss the specific situation of the parent! I'm talking in general. I also agree that not 100% patients with severe chronic pain will consider suicide, however the percentage of people considering suicide in such group is much higher than in the rest of the population.

You may believe so right now, but that's totally irrelevant: just as you were unable to imagine "how much pain it was possible to feel" before your experience, you are unable to imagine what a serious, chronic pain can do to you.

Chronic pain is a lot like depression: there's no relief, no hope, nothing you can do to ever feel any better. Assuming that you'd be able to do anything - and that doing that would even make you happy - is... well, very improbable, to say the least.

> Anyway the point is, not everyone is afraid of pain and suffering. > Especially not to the point that suicide would even be considered.

Sure, it's easy to be brave in the face of the unknown. It's a lot harder to be brave once you see what "chronic pain" really means. And there is no notion of being brave (or not) once it actually happens to you - there's only despair and suffering. Really, _only_ that. Nothing else, at all.

We have a lot of pain management methods at our disposal now and, in many cases, it's possible to reduce the symptoms and make the patient feel "well enough". Without such help, however, it's only a matter of time before (most of) the patient considers suicide - no matter how brave and "suffering accepting" he was before.

<comment><USER5> I've torn the ligaments in my ankle and I've been in chronic pain every day for the last 12 years. Honestly, it doesn't bother me. (I mean, it hurts a lot and given the choice to be alive AND have it gone, I would prefer it gone, but, meh)

It bothers people around me that I limp though. Oh well.

I gave the example of acute pain because that was more challenging to me than the chronic.

<comment><USER7> Interesting. This is a complex issue.

I have those types of issues too. Most of us do once we get old enough.

They don't really bother me. Like yours, I can overcome them. Almost everyone does.

I suspect if either of us had trained all our lives to be, and wanted to be professional runners, it would bother us greatly.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Maybe we should just add lithium to the water supply, although that would drive conspiracy theorists crazy!

[http://www.ncbi.nlm.nih.gov/pubmed/1699579](http://www.ncbi.nlm.nih.gov/pubmed/1699579)

"Using data for 27 Texas counties from 1978-1987, it is shown that the incidence rates of suicide, homicide, and rape are significantly higher in counties whose drinking water supplies contain little or no lithium than in counties with water lithium levels ranging from 70-170 micrograms/L; the differences remain statistically significant (p less than 0.01) after corrections for population density."

Edit: on a second thought, it wouldn't drive them crazy, it would literally calm them!

Edit 2: I'm not proposing adding therapy-level doses of lithium to the water, just equalizing it to the water in other regions.

<comment><USER9> I made that argument in a prior thread and people were really, really against it. Despite the abundance of evidence, from that study and the Japanese one [1]. I think Zinc would make a good addition too re: suicide [2]. There are two other large scale studies like this for lithium, both confirming the findings. One from Greece [3] and one from Argentina (can't find it...) [1]: [http://www.ncbi.nlm.nih.gov/pubmed/19407280](http://www.ncbi.nlm.nih.gov/pubmed/19407280) [2]: [http://www.jad- journal.com/article/S0165-0327(13)00626-5/abs...](http://www.jad- journal.com/article/S0165-0327\(13\)00626-5/abstract?cc=y=) [3]: [http://www.ncbi.nlm.nih.gov/pubmed/24072668](http://www.ncbi.nlm.nih.gov/pubmed/24072668)

<comment><USER10> It's fine if you want to medicate yourself with lithium, but it's not acceptable to forcibly medicate everyone else.

The studies you linked to show an interesting correlation between lithium in water supplies and reduced suicide levels, but you can't judge the net benefit on a single metric alone. Lithium is not without side effects, and it's unreasonable to suggest that the vast majority of the population that is otherwise healthy be subjected to those side effects for the incremental benefit of a select few. The magnitude of these side effects may be relatively small in the levels we're talking about, but the net effect is likely not negligible when applied to entire populations over the course of their lifetimes.

<comment><USER9> Lithium is an element, not just a medication. The element is used to medicate people with bipolar, in huge dosages. You and I both consume lithium every day. We may consume slightly more or less than others. The ones who consume slightly more kill themselves significantly less, with no side effects. Lithium the medication is in 100-1000x the dosages, hence the side effects. If it is bad in high (but naturally occurring, and much lower than the medication) doses, we should filter it out.

<comment><USER10> > Lithium is an element, not just a medication.

It doesn't matter if you call it an element or a medication, it has non- negligible medical effects and side effects. If it had no relevant effects, we wouldn't be discussing it here.

> The ones who consume slightly more kill themselves significantly less, with > no side effects.

"No side effects" is an impossible claim to make. The studies we do have show a _correlation_ between lithium in the water supply and suicidal frequency in the population. The side effects have not been studied.

For some hard evidence: Lithium in drinking water is correlated with changes of thyroid function: [http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3114818/](http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3114818/)

Lithium most certainly does have side effects that are dose- and time- dependent. The side effects may be minimal at low concentrations, but when applied to a population over the course of a lifetime, they would certainly add up. Especially for those who are most susceptible to the negative effects.

It's also not hard to imagine that lithium's suicide rate reduction effects (which are purely correlation at this point, FWIW) are due to it's tendency to mellow people out. The cognitive dulling of even small amounts of lithium orotate in healthy (non-bipolar and non-suicidal) people are palpable. Would you still advocate for lithium in the water if it reduced the average intelligence of the population by, say, 1%? I'm picking hypothetical numbers here, but the reality is that there are certainly downsides to mass-medicating people with small doses of lithium.

<comment><USER9> In that study, the water the people were drinking was up to 20x what was on the high end of the other study. If you are drinking water that is 20-100x higher in lithium, that is more like taking the lithium pills than it is like getting it from water. Further to that, the study proved nothing statistically significant... So if 20x higher lithium concentration causes no statistically significant downsides, what could the harm of being on the upper bound of what is typical in areas that are not lithium mines be?

</comment></comment></comment></comment></comment></comment><comment><USER11> > One of the most amazing things about suicide is that over the past 80 years > or so in the United States, suicide rates have been extremely flat. The fact > that suicide rates have not changed in response to changes in medical > technology and other ways of life is astounding.

This may be true in the US, but in Greenland it seems like suicide rates have changed in response to changing ways of life:

[http://www.npr.org/sections/goatsandsoda/2016/04/21/47484792...](http://www.npr.org/sections/goatsandsoda/2016/04/21/474847921/the- arctic-suicides-its-not-the-dark-that-kills-you)

<comment><USER12> An obvious question is whether suicide rates are _unchanged_ , or simply _flat_ because we have opposed changes obscuring the data.

There's a bit of variance in the US numbers, and I wonder how means reduction, a decline in chronic pain/terminal illness, and various way of life changes compare. I'd be surprised if none of those things were relevant, but less surprised if they didn't add up to a clear trend.

</comment></comment><comment><USER13> There's this AMAZING scifi story, which I read in 'Writers of The Future' (great series, named after the eminent L Ron. H.). It imagines a future where after a certain age, everyone has a chip planted in them, which makes it possible to kill oneself 'on demand', painlessly, so to speak. It 'naturally selects' away all those who are uhh, more instably minded, and selects for the very very 'stable' minded. I believe the story was about how boring, unimaginative the society had gotten because natural selection had optimized for stability. Great read! You should read it if you haven't. The writer's of the future series is a collection of amazing stories also, and what finally tipped me into the Sciences, despite the somewhat uhh interesting Scientology connection. Anyone remember the name of the story?

This was inspired by @antiquark's comment: >>Probably has something to do with the theory of natural selection.

</comment><comment><USER14> Remember that it's technically a valid evolutionary strategy to live to, say, 25, have a few kids, then off yourself. Suicide _before_ reproduction is all that would be selected against.

<comment><USER15> Depends on how much your children need you actually. I've read somewhere that part of the reason women lose ability to bear children past around 40 is so they can take care of their grand children because that is usually more important at that point from an evolutionary point of view.

It might have been a mere speculation but it kind of makes sense.

Rather than take the time to bare and raise one child, that time is better spent taking care of your 6 grand children.

<comment><USER16> I dislike these kinds of explanations because they seem like ex post facto rationalizations. An explanation that could have gone both ways explains nothing:

* Women stop having children after 40 because it's more important to raise the children you already have. * Women don't stop having children after 40 because bearing more offspring increases your chances of survival.

Your explanation barely makes sense even on its own merits. Surely, if nature wanted us to have N children and then take care of them, it would have set a cutoff on N, rather than on the time. What if someone has no children before 40? Is it to their evolutionary advantage to care for the children they didn't have?

Or, if your explanation were true, why would women not spend ten years gestating and given birth to a healthy 10-year old? It's illogical to design a system that can pop out one baby every nine months and then say "okay now that you've had anywhere from zero to thirty children, it would be best if you stopped and took care of them.

<comment><USER17> > It's illogical to design a system that can pop out one baby every nine > months

To design? Are you a creationist?

Assuming you're just confused, evolution doesn't "design" life. It's just a "whatever works" process.

For example, angler fish have a lure that resembles prey for their prey. This has been selected by the eyes of their prey. It's not that the prey _wanted_ their predator to fool them, it's just that angler fish with bad lures starved and died off.

In the case of humans, _if_ what your parent comment suggests is true, then it would just be that some women had some sort of defect where they couldn't give birth after some point and that turned out to give their grandchildren an advantage over the grandchildren of women without the defect. Over a long period of time, more and more descendants with defective reproduction genetics would survive compared to those without and so it becomes prevalent.

That's how evolution works.

<comment><USER16> No, that's how you explain things after the fact. If women could bear children until they died, we'd explain it by saying "well that's obviously because it's more advantageous to have more children". Again, something that can equally well explain why something happened and didn't happen doesn't have any explanatory power.

Put it another way, if I asked you "would you think that evolution would select for women bearing children until their 40s, or until they died?", you wouldn't be able to answer, because there's no predictive power in the explanation. Contrast this with "the sun rises every day because the earth revolves around itself", which allows you to predict whether the sun will rise or not tomorrow.

<comment><USER17> > that's how you explain things after the fact

I agree, that's what I said "if what your parent comment suggests is true"

In fact, said parent comment said "It might have been a mere speculation but it kind of makes sense"

I agree with you that there is no predictive power in explaining things that way (indeed, what I said is speculation, hence why I worded it in the conditional), but that was not what I was responding to. I was only responding to the "design" part of your comment.

That being said, evolution _does_ make predictions which have been confirmed. Notably Darwin's long-nosed moth. Here's a list of more predictions[1]

[1] [http://chem.tufts.edu/AnswersInScience/evo_science.html](http://chem.tufts.edu/AnswersInScience/evo_science.html)

<comment><USER16> You seem to have fixated on one word in my comment and are arguing against creationism. I'm not saying that evolution makes no predictions, I'm saying that saying "oh yes, everything is the way it is because it confers an evolutionary advantage" is a mostly wrong, largely useless answer.

<comment><USER17> > You seem to have fixated on one word in my comment and are arguing against > creationism.

Well, I would argue that the vibe of your whole comment was coherent in that sense: you talked about what nature _wanted_ , about design and about what kind of stuff would make sense while looking at it from a architect perspective.

It's a very odd way to look at it if you have no creationist conception of it all to be honest.

As for your point that not everything has an evolutionary advantage, I agree. Deafness and blindness exist after all.

But I don't really see your point as far as proposing hypotheses to account for certain prevalent traits, which, in my opinion, is what the original content was about (the grandmother hypothesis).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> >The fact that suicide rates have not changed in response to changes in medical technology and other ways of life is astounding.

Because depression is a disease, its not just feeling blue because something happened to you and as such it probably has has the same distribution since the early days of humanity. Its a disease with no good treatments so we can expect the same mortality rate.

I think handwringing over people having easier lives but still killing themselves is fairly meaningless, and frankly, more than a little shaming. Depression affects people almost randomly. Wealthy people with easy lives kill themselves just as readily as poor people with harder lives. You can't will yourself out of depression because things are easy for you. The disease, unfortunately, doesn't work that way.

I have major depression. Its not caused by some negative life events or my parents not loving me or anything like that. Its clearly something I was born with or rapidly developed when I was just a child. I think its dangerous to talk about depression as not being a disease of the brain and as something that emerges from negative life events. Those things can certainly make it worse, but depression is a disease like any other, not a mood.

</comment><comment><USER19> I love how far philosophy has come. This is very science based and yet my first reaction to the article's title was Cmd+F..."Camus". As Camus would say it seems obvious that we realize life is stupid and we should just kill ourselves but—something I didn't realize when I suffered with depression was—that when you realize everything is stupid and meaningless you find this deep appreciation or what I call "the game." You find a competition with "meaninglessness" and even suffering. And I love that game. I think people learn to love life; they find meaning in life and so they keep going.

</comment><comment><USER20> > virtually all adults have the intellectual wherewithal to take their own > lives

Do they? It's one thing to say 'i dont want to live' or "i wish i was dead", and another to actually go through the processes to do that. Suicide killers for example, need a strong metaphysical motive and promise of reward to do that.

I often wonder if a man stranded alone in an island , without any societal pressures would ever consider suicide.

<comment><USER21> > Do they? It's one thing to say 'i dont want to live' or "i wish i was dead", > and another to actually go through the processes to do that

I think everyone has the capability, just as they have to murder. That they have not found circumstance such that they can conceive of it taking place doesn't mean they can't. People discover surprising (for good and ill) things about themselves when pushed to their limits and beyond.

> I often wonder if a man stranded alone in an island , without any societal > pressures would ever consider suicide.

Whilst they'd be free of debt collectors, divorce, job loss, shame and the various other factors that may increase suicide, they'd also have new factors. For instance perhaps the island has no, or inadequate food and water. If you had a revolver and the prospect of starving to death considering surely suicide may be considered?

What of disease or serious injury?

</comment></comment><comment><USER22> How do other primates behave in this regard? I'd expect various coping mechanisms exist to reduce stress becoming so high that the individual contemplates suicide as a solution, i.e. I'd expect it to be more common the individual experiences cognitive dissonance, followed by denial, withdrawal, misdirection, etc. to avoid having to directly deal with the stress inducing information/situation. Suicide requires planning, so it's a very cognitive process, where many of our coping mechanisms are more automated (even if learned, typically that's at a very young age).

</comment><comment><USER23> According to the link, around 1 in 100 people commit suicide. It could be argued that this is a rather high number. Certainly any other diseases that achieved this would receive significant attention.

What is interesting however, is how suicide rates haven't changed with other things like medical improvements and improvements to quality of life.

<comment><USER24> I think you're vastly overestimating how much people care.

[http://www.cdc.gov/nchs/fastats/deaths.htm](http://www.cdc.gov/nchs/fastats/deaths.htm)

Check out, Chronic lower respiratory diseases at nearly 4x suicide. Can't remember hearing a thing about that in the news.

<comment><USER25> You probably have heard of campaigns to reduce smoking. These diseases (e.g., COPD and the related emphysema/chronic bronchitis) are strongly linked to smoking.

In the mid 90s, I remember seeing some anti-smoking campaigns that used people with tracheotomies (see ref 1); these folks almost definitely had lower respiratory disease.

Your point is well-taken - we hardly spoke about addiction as a medical health problem until recently.

[1] [https://www.youtube.com/watch?v=L7bHdo2DJHY](https://www.youtube.com/watch?v=L7bHdo2DJHY) \- this is only part of one of the ads I recall

</comment></comment></comment><comment><USER26> Easy answer: because we want to believe life is precious and that you only live once.

Mental health is taboo.

I'm not trying to say that we should let people die, but the living standard has really skyrocketed, meanwhile we still have behaviors and systems that do damage to mental health, and we still disregard those problems.

<comment><USER15> I think actually it's because we fear death. Even if you're an atheist and know that when you die nothing will happen besides you disappearing, you still don't want to do it. Even people who commit suicide often would rather if they didn't have to use that option.

The worst thing about war in my opinion is not just that people die, but that people live in constant fear of death.

<comment><USER27> > Even if you're an atheist

I really don't understand this sentiment. Surely belief in an afterlife is a far greater motivator to off yourself than not? It's only religions that threaten you with eternal suffering if you do that would act as a special deterrent (easily eliminating all religions that don't have a concept of hell). Especially if you consider that some of those even go out of their way to make exceptions for certain forms of murder-suicide ("suicide attacks").

</comment></comment></comment><comment><USER28> A mistake and an insight.

The idea that white men have the highest suicide rate is misleading - <USER2> have the highest rate of success, which is very likely because they are the most likely to own guns, which are far and away the most effective and effortless way to commit suicide. Effortlessness is important, because depression makes planning so difficult. FWIW I'd really appreciate it if we could not turn this into a debate about gun control.

The insight, of course, is that Elliot Smith didn't have a drug problem, he was looking for a drug solution. This is an incredibly accurate description of addiction. The saying in AA is "If alcohol didn't do anything _for_ me, I'd never have let it do anything _to_ me". Drugs and alcohol are a solution to the underlying problem, one in which we simply can't feel ok the way others can. Of course, they are a solution with horrible side effects, and one that eventually stops working. Many members of AA describe getting sober because the drugs and alcohol weren't working anymore, only to become suicidal and realize that the drugs and alcohol were only symptoms of a much deeper problem.

<comment><USER29> > which is very likely because they are the most likely to own guns

America is not the world

<comment><USER28> I think the data were taken among Americans (they included Native Americans). You're right though, and looking at data from other countries with stronger gun restrictions would be an interesting way to check this hypothesis.

<comment><USER30> In England you can use the Office for National Statistics data sets. These are good quality, and they're very clear about what is or isn't counted as a death by suicide.

[http://www.ons.gov.uk/peoplepopulationandcommunity/birthsdea...](http://www.ons.gov.uk/peoplepopulationandcommunity/birthsdeathsandmarriages/deaths/bulletins/suicidesintheunitedkingdom/2014registrations)

You can also use the Public Health England "Fingertips" datasets which breaksdown the data a bit more.

Here's the main Fingertips site: [http://fingertips.phe.org.uk/](http://fingertips.phe.org.uk/)

And here's the Fingertips mental health stuff: [http://fingertips.phe.org.uk/profile-group/mental- health](http://fingertips.phe.org.uk/profile-group/mental-health)

And here's the Fingertips suicide stuff: [http://fingertips.phe.org.uk/profile-group/mental- health/pro...](http://fingertips.phe.org.uk/profile-group/mental- health/profile/suicide)

Currently the ratio of deaths by suicide for men:women is something like 4:1 or 3:1, and we think that's because (as you've said) men tend to use more lethal methods. (Although we've seen a really worrying increase in lethality of method in women in the UK).

Go careful when comparing the UK stats with the US. I think we count different things. For example: a death that would be counted as a suicide in someone over the age of 15 is not counted as a suicide in someone under the age of 15. I don't think the US does that.

</comment></comment></comment></comment><comment><USER31> The relationship between depression and suicide with age is just correlation not causation, so it's silly to draw a line there and assume they are connected -- especially since we know depressed people have a higher suicide rate than people without depression.

I think this post is an attempt to make an obvious question seem like it has deep or non-obvious answers; but in reality I think the answers are pretty obvious. Most people don't kill themselves because they don't want to. It's that simple. It's like asking "Why don't more humans become ballet dancers?" Some try and fail but most just don't want to.

If the question is really; why don't more people want to kill themselves, then the answer is going to vary person by person and be difficult if not impossible to answer globally. Bob might not have any thoughts of suicide at all but Alice might think about it but want to see her nephew grow up and not inflict that pain on her parents.

Truly answering that question would involve a really comprehensive study of a lot of different groups to even attempt to answer it.

<comment><USER32> The paper does not draw a causation, nor does the article. The paper asks a question, and the article tries to think along the lines of the question and asks some more.

\----

> I think the answers are pretty obvious. Most people don't kill themselves > because they don't want to.

That is a simple conclusion, indeed; and it's not wrong either. The article tries to reason how that conclusion came to be. People who have had suicidal thoughts but didn't go through with it did _ultimately_ not want to do it, but before that decision they did want to, by definition of 'suicidal people'.

The article – inspired by the paper – opens with the premise that 'pain' and 'human cognition' alone should make a human want to 'give up' upon the slightest inconvenience, and then goes on to try and come up with other factors — like your Alice wanting to see her nephew grow up or not wanting to inflict pain on her parents — that prevent 'pain and brain' from having their way uncontested.

<comment><USER33> > The paper does not draw a causation, nor does the article.

It does draw a conclusion:

      > Indeed, there appears to be a slight elevated risk
      > of suicide in people taking some antidepressants,
      > especially young people. But the effect is tiny.
      > And some people do think antidepressants relieve
      > suffering. If depression caused suicide, treating
      > depression should reduce suicide rates, but of
      > course it hasn't. This could be due to the
      > ineffectiveness of treatment, however.

If depression caused suicide, treating depressing should reduce suicide rates ... BUT ... that assumes we identify and 'rectify' all depression, and that the only cause of suicide is depression, and that the only metric of success for treatment of depression is a reduction in suicide (across the board) ... and if you adopt those three positions then the numbers start to make sense.

'But of course' this isn't the whole story.

<comment><USER34> Exactly. Treating the symptoms does not mean treating the cause and might even enhance it.

</comment></comment></comment></comment><comment><USER35> tl;dr, the article mostly discusses Soper's hypothesis that "mental illnesses" such as depression evolved as defences against suicide rather than being the cause.

So I guess rather than thinking the job's crap, I'll just have a jolly skydiving trip with no chute you get depressed instead. There might be something there - I've always been a bit puzzled by the evolutionary function of depression.

<comment><USER36> I'm not sure there needs to be an evolutionary function for everything. Some things are just "dewclaws".

</comment></comment><comment><USER37> Martin Hart: So... what's the point of getting' outta bed in the morning?

Rustin Cohle: I tell myself I bear witness. But the real answer is that it's obviously my programming. And I lack the constitution for suicide.

\--True Detective

<comment><USER38> Time is a flat circle.

 _rolls up a booger between his thumb and index finger_

</comment></comment><comment><USER39> the highest suicide rate is among people 85 years or older. With the advancement of healthcare people are living longer. So the rate of suicide amongst younger demographics most likely has declined slightly

<comment><USER15> Interesting. I've often contemplated about it. I don't think I want to live past 80. I mean unless there would be a medical revolution where you can retain youth or slow down aging significantly.

<comment><USER40> Get back to us when you turn 80. :)

People's experience change their perspective. What's important to you now will change. What you're able to appreciate changes.

<comment><USER15> I actually used to have that limit set to 60, but then when I thought about it, I probably would still have some physical strength at 60 and still wouldn't want to die. But at 80 I can't imagine myself being other than a total wreck.

<comment><USER41> My grandfather is 89. He can't walk very far, he gets tired very easily, and he has arrhythmia - yet he is still very strong, and very active. Most days, he gets up at 5, works in the garden, or the woodworking shop, or on property maintenance, finishes up by noon, and watches television until evening. This has been more or less his routine for the past 13 years.

If you remain active through your life, I think you're much more likely to stay active as you're older. I intend to retire by 40, but I don't intend to be idle.

</comment></comment></comment></comment></comment><comment><USER42> OK, now that I see the stat he's calling "low", 1.4%. I actually disagree. That's a pretty high number that we could probably get to go down further. Assuming that one person out of every graduating high school class is going to kill his/her-self would seem to me to be a fairly morbid assumption. But this appears to be the case.

I think the responsibility for the weight (or perhaps, levity) of the philosophical observations made in this article fall back only on the writer himself, and his own attitude(s) towards suicide.

<comment><USER43> He did the math wrong. The source he links shows about 10 deaths per 100,000 which is .01%. He's high by 2 orders of magnitude.

Edited to add: The highest by-country rate using the statistics he cites is Guyana at 44 per 100,000, which is .044%: [https://en.wikipedia.org/wiki/List_of_countries_by_suicide_r...](https://en.wikipedia.org/wiki/List_of_countries_by_suicide_rate)

</comment></comment><comment><USER44> This question is much more interesting when you realize that modern neuroscience is (slowly) going more and more into area that there is no free will in humans.

What is a reason to live if they are not your decisions driving it? Skipping over all (judical etc) consequences, if this is true, then life has no sense and it's more/less ok to end it - what's funny, suicide would also not be your (as in free will) decision... Meaning this is a time bomb programmed into any thinking brain (and any AI as, what's double funny, this logic also applies to any AI).

Dodge that homo sapiens :)

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

[https://www.amazon.com/Free-Will-Sam- Harris/dp/1451683405](https://www.amazon.com/Free-Will-Sam- Harris/dp/1451683405)

<comment><USER45> > This question is much more interesting where you realize that modern > neuroscience is (slowly) going more and more into area that there is no free > will in humans.

Science _inherently_ approaches the universe in a way which leaves no room for materially meaningful "free will"; only strict material determination and _randomness_.

<comment><USER46> I don't think the scientific method is inherently materialistic - it's just that our most validated theories about how the world work are materialist.

</comment></comment></comment><comment><USER47> DNA is a self-optimizing program for its own survival. After millions of years of optimization, ones will to live is quite powerful.

The twist is that the optimization mechanism relies on mistakes in copying itself. One outcome of a copy mistake could be a weakened will to live in certain negative life circumstances.

</comment><comment><USER48> Evolution goes deeper than your rationalizations. Our brains descended from a long line of successful matings that obviously waited long enough to fuck before checking out. Possibly the fucking potential keeps us keepin' on in the lower level of our subconscious. It may also be hard wired preservation (the fear of pain), basic pleasure, caring of others, the illusion of god(s) or some imagined purpose of life, but I would guess mostly the fucking potential drives it all, at least for the younger. There's just a lot of good things to distract us from wanting death. But again, it goes deeper than our rationalizations so its going to be hard to say exactly without in depth scientific studies on the matter.

</comment><comment><USER49> I had a strange mental illness period a few years ago. In my opinion, Dr Peter Breggin and others with similar believes are right. To some people, like slow metabolizers, these psychiatric drugs, are the cause of suicide and other irrational behavior. The author says "Indeed, there appears to be a slight elevated risk of suicide in people taking some antidepressants, especially young people. But the effect is tiny". I think the word "tiny" is the problem here. The effect is not "tiny". It is simply misunderstood or ignored.

</comment><comment><USER50>
      >Close to 100% of humans could suicide, and yet 'only' about 1.4% do

Very bad and misleading wording. 1.4% here is of total number of deaths, not total number of people. Also, both numbers seem untrue. Wiki says[1] "approximately 0.5% to 1.4% of people die by suicide".

1\. [https://en.wikipedia.org/wiki/Suicide#Epidemiology](https://en.wikipedia.org/wiki/Suicide#Epidemiology)

<comment><USER43> As I mentioned elsewhere, this math is wrong. it's 10 to 44 people per 100,000, which is .01 to .04%, 2 orders of magnitude lower than 1%.

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

</comment></comment><comment><USER51> I find this a bit over the top/strange to contemplate

Maybe because I have known people who successfully committed suicide - <USER3> turns out people who survive almost always are thankful/happy they did. In fact, it turns out if you interview people who jump from building and manage to survive, as they fall, they are thinking they wish they hadn't done that...

</comment><comment><USER52> What if not being depressed is the beneficial adaptation? It would not surprise me if many depressed people have a more accurate view of the world and their place in it. When someone's expectations do not match reality it's not normally considered intelligent, but positivity seems unrealistic, common and beneficial to survival.

<comment><USER53> >What if not being depressed is the beneficial adaptation? It would not surprise me if many depressed people have a more accurate view of the world and their place in it

It's funny that you should mention that...

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

</comment></comment><comment><USER54> I got really scared for a while because I was both suicidal (the idea itself gave me an endorphin rush to think about) and my energy levels were fairly normal / I wasn't showing other symptoms of being depressed. Depression as a mechanism for preventing suicide sounds plausible.

</comment><comment><USER55> Reminds me of this quote:

> If there wasn't the possibility of killing myself, I would have killed > myself!

</comment><comment><USER56> Altruism. You believe in the human race -- perhaps despite being majorly screwed by some individuals. You just no longer believe in yourself.

I'm about there, myself.

P.S. When I wrote this, I missed the "few" in the title.

</comment><comment><USER57> pain, suffering, happiness, evil, good are all synthetic constructs developed by evolution that optimize the feedback loop in which a system of molecules is suck in.

</comment><comment><USER58> I guess it might make sense to compare to suicide rates in non-human animals (e.g. dolphins which can just stop breathing to kill themselves)

</comment><comment><USER59> i think the author misses the data point of actuall doing it, is not easy. He keeps repeating, everyone has the ability to kill themselves, but is this true? I think most people, even if pain is at 100% and desire to do it is at 100% the knife/gun/etc just won't go. So re-think the whole thing from the point that VERY FEW humans have the ability to do it.

</comment><comment><USER60> this is overly simplistic. melancholic depression is roughly 3/4 of all cases, the rest is from bipolar disorder, which makes it more likely to for people to kill themselves. how does this theory explain postpartum depression in females?

</comment><comment><USER61> When its over its over forever. No point rushing.

</comment><comment><USER62> You don't seem to understand much about evolution, or life. Claiming that evolution is a random, unguided "whatever works" process is mere ignorance. To everyone who has ever looked around (or listened around, or sensed around) even for one moment, it is beyond obvious that not only evolution works "by design", but that this design is supremely personal and the ultimate in creativity. So the implied negative connotations in your "creationist" label are misplaced.

<comment><USER63> We detached this subthread from [https://news.ycombinator.com/item?id=12165775](https://news.ycombinator.com/item?id=12165775) and marked it off-topic.

</comment></comment><comment><USER64> Probably has something to do with the theory of natural selection.

<comment><USER26> Well in society artificial selection seems to have much more influence on us.

<comment><USER65> Society is natural.

<comment><USER26> Government, laws, science, technology, management? Do all those things appear in nature without our initiative? They seem to be made by humans.

I don't really know. Ultimately you can argue that everything happening in the universe is natural, but I would make a difference between things created by intelligent creatures and the things that appears with natural selection. That doesn't involve intelligent design.

<comment><USER65> Many other species have different forms of complex societies.

</comment></comment></comment></comment></comment><comment><USER66> It's always strange to see someone wondering whether skin pigmentation has something to do with something completely unrelated like mental health or suicide rate, when so many other factors with demonstrably more impact come into play (social, economic, etc).

<comment><USER67> Yes it's not like skin pigmentation correlates with anything at all. The author is surely suggesting that skin color is _the cause_ and that's just silly.

</comment></comment><comment><USER68> The relevant question is "Why so many humans kill themselves?". Because asking the other way around implies suicide is natural, which is a ratter extraordinary claim.

<comment><USER69> Perhaps. But it is also pedagogically valuable to ask "Why don't more people commit suicide?" We might learn something about the mental defence mechanism the brain employs.

<comment><USER70> Pedagogy /can/ go off the rails if it places other goals above the elimination of human killing. I know this is self-evident, however there are many hidden killers out there so consider this a billboard.

<comment><USER71> There's no ethical reason to oppose suicide, in general. Many cultures valorized it in certain situations.</comment></comment></comment></comment>