I'm guessing they chose the weird spelling for the same reason that so many companies choose weird names: domain name squatters.

Perl is hardly an example of improvement. Its widespread usage despite its fundamental flaws has given us a large body of software that is often entrenched and almost always a maintenance nightmare. I hope our OS distribution maintainers have the sense not to repeat that mistake with our init system.

I don't have any experience with malicious flash drives, but since we're on the topic of fakes, F3 is a handy test program:

http://oss.digirati.com.br/f3/

Facing a similar problem a couple of years ago, I discovered that yahoo provides email filters not only for its webmail users, but also for several other companies. They have a procedure for requesting an exemption from their filters. It took a couple of tries, but I eventually got my server accepted. Here's the form:

http://help.yahoo.com/l/us/yah...

I've observed the same behavior in software development, particularly in the open source world. Some project maintainers are happy to have people helping by reporting the problems they find, while others will deny that a problem exists (and sometimes go as far as trying to discredit the reporter) if they don't happen to be affected/bothered by it. I guess inconvenient truths are hard for some people to accept.

As far as I can tell, there has never been any statistically significant evidence that redefining time twice a year saves any energy, or has any other net benefit at all.

Meanwhile, it continually wastes the time of people who have to deal with the problems that it causes; moreso than ever since the world started depending on computers, and since international interactions have become common.

Just get rid of it, please. Forcibly playing games with people's clocks in the name of pretending that seasons don't exist is just stupid. Let businesses adopt winter hours if they want to align with daylight.

"Democrats and republicans can twist any topic to be a battle between democrats and republicans."

FTFY. :)

So it's basically carte blanche for anyone with a job in in politics, law enforcement, or prosecution to destroy the life of anyone they choose, based on nothing more than conjecture. Does anyone else find this frightening? Would the dangers of this idea be more obvious if the words "computer users" or "hackers" were replaced with the word "people"?

I ran into that same problem with Skype's latest release. Rather than giving Pulse a fourth chance to burn me, I decided it might be time to give WebRTC a try.

I'm so glad I did. OS-independent browser-to-browser video chat worked fine. I used Chromium on linux while my friend used Chrome on OSX. The latest Firefox release supposedly supports h.264, so it might work as well. Here are a couple of call set-up sites in case you'd like to try it for yourself:

https://opentokrtc.com/

https://vline.com/

So your answer is "trust the user".

No, my answer is that we are already trusting the user, a password authentication system cannot ever be more secure than that trust, and neither system can solve the problems upon which you based your assertion.

That's okay. I don't need to draw this out any further. I just wanted to unerstand how you came to your conclusion, and now I believe I do.

Can someone tell me how to get Firefox to say which protocol it's using for any given session? The Security tab has a Technical Details section that mentions "High-grade Encryption" and TLS, but it doesn't say which version of TLS.

Can you link to the documentation for this? I'm too lazy to search for it right now. :)

"Very few sites (even tiny web forums and such) are willing to trust arbitrary 3rd party."

Those sites wouldn't be trusting a third party; they would be trusting the user. Specifically, they would be trusting the user not to delegate his identity to an impostor-friendly provider, just as they are now trusting the user not to re-use his password on any site that will some day have a database leak or cleartext login form. Anyone who thinks his onsite auth buys him greater security than OpenID either has some magic way to force people into choosing unique passwords, or is sadly mistaken. I'll let you guess which is more likely. :)

I'm curious where you got the "very few" metric. Anecdotal evidence? A study with a large and diverse sample size? If you have some study results, I'd like to bookmark them. I guess it would just go to show that very few admins have a good understanding of overall security.

"There are other problems, like ensuring unique, non-spam/bot users, that can't be done with remote authentication"

Local password authentication can't solve those problems either. Bot and spam problems are solved by other means, like captchas and request rate throttles. Sane sites do this when an account is created, not every time a known-good user wants to log in. Some really careful sites take additional steps during login (like click/request/response timing), but those steps are invisible to the user and can be applied regardless of whether a local password is used.

"We do, it's called Open ID, which is what Google leverages for their single-signon (not sure if FB is their own solution or not). It was a really popular thing about 5-10 years ago and got a ton of attention. I think even MS enabled it."

OpenID 2.0 accomplished something very cool: allowing a user to use any ID provider for authentication on any compatible web site, even if the two sites had never heard of one another. Unfortunately, it has two major problems:

• It's too complex to easily implement. This became less of a problem once OpenID libraries like Janrain's emerged, but there are still subtle details left up to website developers to get right, and since many of them don't bother, a lot of sites that supposedly accept OpenID actually fail with some providers.
• Perhaps more importantly, the URL-based IDs are not user-friendly enough for non-geeks. Several high-profile sites tried to solve this problem by replacing* the OpenID URL input box with a simple button for each well-known provider, but that meant limiting the user's choices of provider. At that point, the distinguishing feature of OpenID was lost, so lots of sites chose the simpler-to-implement OAuth 2 instead. The Login with Facebook service is one of them. Even Google eventually deprecated their OpenID service.

In my opinion, the issue of relying parties not trusting someone else as an identity provider was not such a big deal; certainly not enough to have killed OpenID. For every such distrustful site, there are dozens more simple web forums and the like that would be happy to get rid of their password database.

*stackexchange is a notable exception; they still offer the input box if you click a link.

I think I'm glad to read this news, especially right now, because it might motivate someone to develop a better alternative.

I'd like to see something like this:

• Starts services on demand based on dependencies, not based on order like sysvinit or events like upstart.
• Has a minimal core that can easily run on its own, just to do the job of a standard init system.
• Is easy to learn, configure, and understand.
• Has good documentation.
• Does not encourage application software to require it.
• Does not encourage other system services to require it.
• Works well on linux and non-linux unixes.
• Is a lot less buggy than the stuff that I've seen from systemd's author.