"mpg123 has no controls..."

It does with the -C option:

    -C, --control
        Enable  terminal control keys. By default use 's' or the space bar to
        stop/restart (pause, unpause) playback, 'f' to jump forward to the next
        song, 'b' to jump back to the beginning of the song, ',' to rewind, '.'
        to fast forward, and  'q'  to quit.  Type 'h' for a full list of
        available controls.

It's actually a very competent player, even able to play streams. Mplayer and cmus are also very good for audio playback in a minimalist environment.

Doesn't it seem that configuration is needlessly complex for certificates? I think it would be easier to list the entire chain in one directive:

    TLSCertificates /path/to/host.crt /path/to/intermediate.crt /path/to/root.crt

That would support any number of intermediates and remove the need to concatenate certificates into a single file. Terminating with the root certificate would be optional, but if present the server could perform a check to verify the chain to the very end when starting.

I'm guessing your third sentence triggered a penalty. Replace "current captchas" with a blank and you'll see why.

I agree that the reCAPTCHA experience is terrible and assume many others agree with you, in part spurring the development of this new approach. I don't believe that every reCAPTCHA has a solution, or at least a consistent one, so I always feel like a percentage of time wasting is built-in. To work around it, I usually regenerate it until I get one that looks easy, but it's still frustrating. Improving the odds of getting it right the first time will help improve the experience a bit. But my biggest gripe is that they can make direct downloads impossible for resources that don't require extra protection.

I always assumed Google's use of reCAPTCHA was to augment the OCR used to digitize Google Books, particularly in results the software couldn't confidently match to a word. Is this true? It's interesting that it's still the fallback for the new method.

That was the original goal of the project.

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

"By presenting two words it both protects websites from bots attempting to access restricted areas[2] and helps digitize the text of books."

For some time, you could pass a reCAPTCHA test by just entering the more distorted word correctly.

This should be the top thread. I find the whole topic of crowdsourcing to compensate for the inadequacies of computer vision (and other inadequacies) fascinating. OCR was the first problem. We've been helping Google Maps identify house addresses for a while now with reCaptcha, and with this announcement it looks like Google is finally tackling the problem of image association. Computers suck at determining which pictures contain birds. By making users tag all of the images on the web, they're making image search much more powerful and will hopefully improve the entire field of computer vision.

When I tell my future robot to go get my coffee mug, I don't want it coming back with the PS5 controller.

I only ever enter the distorted one, works every time.

That was the original idea behind reCAPTCHA (which originated outside of Google, acquired in 2009), but my understanding is that they long ago ran out of actual text that needed human OCR'ing, and/or found other reasons that approach no longer was helpful.

The "help OCR while also spam protecting" thing isn't currently mentioned on Google's recaptcha product page.

It is:

> Creation of Value

> Stop a bot. Save a book.

> reCAPTCHA digitizes books by turning words that cannot be read by computers into CAPTCHAs for people to solve. Word by word, a book is digitized and preserved online for people to find and read.

https://www.google.com/recaptcha/intro/index.html#creation-o...

Good catch.

I wonder where i heard/got the impression that it wasn't really being used for this much anymore. Maybe from when most of the recaptchas most of us saw switched from scanned books to google street view photo crops. And I was also surprised by the implication that google's algorithms really needed human help for visual recognition of almost exclusively strings of 0-9. I would have thought that would be a pretty well solved problem.

Anyway, somehow I got the idea that recaptcha wasn't actually providing much OCR help anymore, but maybe I just made that up.

For the past few years the recaptchas I've seen were illegible text next to easy to read text. I think its obvious that they've run out of the low hanging fruit and now just have the worst of the worst as placeholders. The move to house numbers just proves that they're kinda running out of badly OCR'd text.

This move isn't too surprising. OCR based captchas have always been a hack and the "best" captchas are like having the best collection of duct tape and WD40. At a certain point you need to stop doing half-assed repairs and remodel.

they also used it to decode street number addresses, for street view

"Get a decent editor and don't leave whitespace at the end of lines."

Trailing whitespace always raises a huge red flag for me whenever I look at someone's code. It's not just sloppy, it often makes diff output so noisy you can't detect real changes to the code.

I understand that it would be bad to introduce whitespace-only changes, but why would whitespace at the end of the line that doesn't break the 80 character limit be a problem otherwise? Sure, git colors them red in its diffs, but that is kind of a circular reasoning.

E.g. in this diff

  0a1
  > k=2 
  2c3,4
  <     print(i)
  ---
  >     k*=k 
  >     print(k)

you don't even see the spaces after "k=2" and "k*=k".

Who cares? Get a decent editor that doesn't give a crap if there's invisible whitespace at the end of a line.

As the top commenter said, the problems do not end with choosing a good editor and fixing its display methodology. Git and many other VCSs create noisy diffs whenever space is added and forgotten, which ultimately complicates the life of developers that want to review changes. Even if your editor were able to make display diffs in a clean way, you would still have a dirty history when for instance using less/more or other tools (not to mention the merging issues problem).

> Git and many other VCSs create noisy diffs whenever space is added and forgotten, which ultimately complicates the life of developers that want to review changes.

That's because Git is stupidly opinionated about end-of-line whitespace, having been written by .... Linus.

Right, but that's only half of the robustness principle.

or run perl -e s/(.*)\s+$/$1/g

I thought the whole point of High-DPI was to was to free us from the need to render graphics pixel-perfect at native resolution. While scaling bitmaps will probably be necessary for photographs and most video for a long time, can't everything else be rendered using SVG? Does such an environment already exist?

There was a good discussion of this topic yesterday in the iPhone screen thread: https://news.ycombinator.com/item?id=8634662

I've just set up 3 different work areas consisting of laptops with external second monitors. I've settled on the configuration having the external monitor above the laptop display as being the most optimum. I find that I never need to move my neck to glance from one screen to the other, and only require a slight tilt at the waist to comfortably switch for longer periods. Contrast this to a side-by-side configuration, where it feels awkward to merely shift my eyes sideways, so I move my neck more. This in itself isn't so bad, until I need to focus on one screen that's off-center for prolonged periods, keeping my head in an awkward angle that doesn't seem healthy. Naturally, any configuration should still be augmented with regular stretching/activity breaks.

tl;dr: Vertical: Mostly eye movement. Horizontal: Lots of neck movement.

I run Apache httpd, and there's no way I'd let a wizard anywhere near my configuration files or private keys, much less run it on a production server.

I think it's about time for a free CA that is recognized by all clients, but you still need to establish a trust chain to exchange a CSR for a signed certificate. This service needs to be server agnostic. The barrier to adoption isn't configuration, and HTTPS isn't the only thing that uses certificates.

There are lots of different barriers to adoption. With this project we are attacking several of them at the outset, including the cost of obtaining a certificate, and the inconvenience or difficulty of obtaining and installing it for users who don't do that every day.

Because of the open protocol we also aspire to support users with more complex configurations and requirements, who are absolutely welcome and encouraged to write their own implementations of the protocol and integrate with their own existing certificate management and configuration methods. If you think of other barriers to adoption that we can help with, please let us know and we'll try to address them; if you just want our certs for free, please get them and enjoy!

My concern is that your reach is too far. Asking domain administrators to trust your software to manipulate private keys (and server configurations) is as troubling as asking end users to click past security warnings. The whole purpose of the CSR is to obtain the signed certificate without putting the private key at risk. This decoupling isolates the challenge of identity verification in a reasonable place (nobody is saying it's easy). With your client, you're essentially telling people you accept checks or credit cards, but only if they show you their gold. It sets a bad precedent.

I do want your certs for free! But I also want/need to trust you and know that you're following best practices, not just with me but with everyone.

Oh, our software does NOT send the private key to the CA. Never never never never. The point of having it manage the keys is not to give us access to them, it's to be convenient for the end-user, on the end-user's own system, under the end-user's control.

You can tell because our software is open source, written in Python.

https://github.com/letsencrypt/lets-encrypt-preview

We expect the users to get this software from their operating system repos, like from the Debian package repository -- the very same place they get their Apache or Nginx packages. We are not asking people to get the software directly from us, or to use it without being able to read it and check that it's safe and does what they want.

Edit: And if you want to implement your own client, we encourage you to do that -- the more clients the merrier!

I'd still be more comfortable if the process never went anywhere near the private key (and I'm concerned that a proprietary competitor or look-alike would prey on naive users by leveraging your example). But I also applaud your effort and transparency. I admit I trust openssl to manage my own keys and certificates, and there is definitely room in this space for improvement and alternative approaches. But it does sadden me that we risk making administrators as trusting and ignorant of the underlying principles as end users already are today.

I have this to use the arrow keys without any modifier:

    # Use up/down arrows to search on partially typed command
    bind '"\e[A"':history-search-backward
    bind '"\e[B"':history-search-forward

Just type the first letter(s) and use the up/down arrows to scroll through the filtered command history. Incredibly convenient.