'oping' fixes that issue:

  $ oping msn.com
  PING msn.com (23.101.196.141) 56 bytes of data.
  echo reply from msn.com (23.101.196.141): icmp_seq=1 timeout
  echo reply from msn.com (23.101.196.141): icmp_seq=2 timeout
  echo reply from msn.com (23.101.196.141): icmp_seq=3 timeout

Also, in standard ping, you can type Ctrl+\ (sends the QUIT signal) to get an update, e.g.

  $ ping msn.com
  PING msn.com (23.101.196.141) 56(84) bytes of data.
  <<< Ctrl+\ >>>
  7/0 packets, 100% loss

ctrl+break does the same on windows ping.

based on a quick perusal of the man page, the -O option will show something like "no answer yet for icmp_seq=19" when a packet doesn't get a response in time for the next one, and at least for me the default shows the icmp_seq which increases by one for each packet sent, but is only printed on each receipt (so you can spot missing ones).

I use mtr nowadays. It's not ping but a traceroute that updates as it goes. I find it much more useful than a plain ping in most cases.

> Am I the only one that finds the MS Windows ping more useful for quick troubleshooting that the Linux/Unix variants?

If you can read the output, or just recognize the difference between successful and unsuccessful lines, it works just as well for this.

> Is this a fundamental design flaw?

It's handy UX, but not the fundamental purpose of ping.

On current iputils ping (seems to be default on most linux distros) you should be using flood ping for this:

    # ping -f x.x.x.x

As superuser or su -c / sudo of course. You'll get a nice real time bar chart of packet loss. I use it all the time for (edit: local) network testing.

That's fine on your local network. If you're pinging a system out of your local network, what you're doing is considered by many to be a denial of service attack.

http://en.wikipedia.org/wiki/Ping_flood

It's not even close to the most effective denial of service attack, but if I were to do that from my 100 Mbps Internet line I could overwhelm many company's Internet lines with a simple ping flood.

Sure. I added "local" about a second after posting for this reason. However even with -f you can just specify an interval when running tests outside your lan.

It still writes icmp_seq, which increases by one for each subsequent packet sent - based on this you can spot any missing responses. Indeed not as visible as in Windows though.

One theoretical problem with this is that it's impossible to know for sure that a packet has been lost and there's no one-size-fits-all timeout to use. On most links it doesn't matter too much, but that may be the reasoning. I've seen ping times spike in excess of two minutes on real-world internet connections (abusing 1xRTT data through a RAZR back when those were still cool) and it was... if not useful, at least interesting, to know that the data wasn't actually being dropped but was just taking a really long time.