Off-topic and completely wrong, both! Apologies for continuing the off-topic thread (and maybe feeding the AC troll), but CENTCOM is apparently channeling the old Iraqi Minister of Information now, and I think this is worth correcting for anyone not paying close attention.

Yes, but that isn't remotely the same thing as saying the strait is open. That small southern corridor couldn't handle anywhere close to the normal traffic volume, and shippers mostly still don't dare try. Insurance on transiting ships is 30X higher than normal. As a result of the high risk, high insurance costs and lower-capacity corridor, the tonnage transiting the strait is less than 5% of normal.

Oil prices have come back down, somewhat, but this is because of reduced demand, not restored supply. The reduction is due mostly to China decreasing imports by some 5M barrels per day (a couple of years ago people were saying they were crazy to be building a lot of coal-fired power plants that were idle the day they were commissioned, but those are largely what have made it possible for China to cut consumption by so much), partly by increased US exports (which require high prices to sustain) and partly by ongoing releases from various strategic reserves. China can probably continue its reduced consumption rate almost indefinitely, but unless the strait is really reopened, prices are going to go back up.

Cool story, bro.

The truth is that Iran can just continue doing what they're doing and the economic pain on the rest of the world will increase. The US has not demonstrated that it can degrade Iran's strike capabilities; the US strikes did some damage but never significantly reduced Iran's ability to strike shipping, and Iran has quickly rebuilt what was destroyed. It doesn't take a lot of expensive, hard to relocate infrastructure to manufacture drones, unlike uranium enrichment.

The bottom line here is that the only way the US is going to restore the strait to full operation is by giving the Iranians whatever they want, which will include leaning hard on Israel to halt operations in Lebanon. Trump's decision to attack Iran has massively strengthened the mullahs' position, both internally and internationally.

No. I no longer work for Google so all of the documentation, emails etc. are inaccessible to me. Is there some reason you doubt my truthfulness?

I had some interactions with EFF a few years ago that left me sad. They definitely do a lot of good work, but I had thought they would be pretty good at understanding complex technical issues and their nuanced interaction with social and political issues, but my experience was quite the opposite. They're a pretty blunt hammer, mostly focused on rejecting any technological change regardless of its benefits. Even that would be okay if they were at least able to articulate sound objections, but that also didn't seem to be the case.

I was working on Android and participating in the ISO 18013-5 mobile driving license standardization process. I thought it would be a good idea to consult with ACLU and EFF, partly to get their buy-in, but mostly to get their feedback. I thought they might have concerns that I could help to address either in the standard (though, honestly, the European members of the ISO committee were already going above and beyond with privacy protection and abuse protection -- the Germans in particular are incredibly paranoid about such things -- and that's good!) or in the Android infrastructure I was building.

ACLU was great, at least for a while. The reason it was great was because the ACLU representative I was working with was Jon Callas (former. CTO of Silent Circle and PGP Corp, Chief Scientist of PGP Inc.). Jon is brilliant, with a deep and abiding interest in privacy. He was generally impressed with the approach we were taking, and had some good insights for tweaks we could make to tighten it up. Unfortunately Jon only worked with the ACLU for a couple of years, and we struggled to find anyone to engage at all after his departure. I'm not sure he wants to share publicly his reasons for separating, so I won't go into that (though I will point out Jon's article, linked above, is not an official ACLU position).

EFF... not so much. The EFF folks seemed not even to be able to understand what we were building. They kept comparing it to e-Verify (which they think is unambiguously bad) but were unable to articulate precisely what the problems with e-Verify were, or how those might translate to mDLs. I was actively seeking feedback on concerns that I could try to mitigate through good design and implementation. Their response was just a blanket "no, this is all bad" with no thought behind it, and no consideration for the individual privacy improvements that electronic delivery with selective disclosure provide as compared to plastic cards that just lay all of your personal information out there.

My discussions with police were actually far more productive than my discussions with EFF. The cops recommended pro-privacy tweaks that I incorporated -- their concern wasn't actually privacy, mind you, but liability, both financial and legal. The chiefs I spoke with were very concerned that there not be any circumstance in which a police officer might need to touch your phone, because they didn't want to deal with the crap that would ensue when phones were broken, or illegally searched. They were significantly more tech savvy than you might expect, too, and of course they deeply understood highway stops and other police interactions.

But EFF was just frustrating and useless. Which is too bad because I had always had a lot of respect for them and the work they do. I still do, I guess... I just understand now that they have morphed into a typical lawyer-based civil rights organization. Which is good! We absolutely need those! But they lack the technical sophistication I understand they had when founded.

Yes, the manufacturer of the self-driving system. People have been asking this silly question for a decade now, even though there is no other answer. Google, at least, has stated publicly on many occasions that they are liable for the actions of their self-driving vehicles.

No, they did not. In fact they said exactly the opposite, that the cars are never remotely-piloted. They said that the cars occasionally request guidance, which means something like "Should I go this way or that way?", then the car acts on the answer.

I quit using Windows in 2000, and it's been at least a decade, if not more, since I ran into anything like that.

Dude, you're being ridiculous.

That's clearly not the intention here if the end result of passing through the luxury terminal is boarding the same airplane as those masses, and it is. It's obviously just to make the airport part of the travel experience nicer, in ways that would be too expensive to apply to the regular terminal. It's the same thing as airport lounges (I'm a Delta Sky Club member myself, a privilege I pay money for so I have the option of a nicer place to wait, the availability of hot showers on long trips, food, drinks, etc.) just scaled up to cover the whole airport process... right up to boarding time when the people get shuttled to board with everyone else.

LOL. I specifically mentioned that I use correct capitalization... so of course I screwed up the capitalization.

Tiny, tiny minority. And if you think you want that, you're wrong!

Also, it's worth pointing out that finding matching pages in a database of pages is indeed trivial -- and building that is utterly insufficient, because for any query that trivial matching algorithm will return a huge number of pages. Thousands, even for the most obscure technical terms, millions or tens of millions for more-common words.

The hard part of building a web search engine (and it's very, very hard) is ranking the results once you've found them, so the thing the user wants is on top. That was, in fact, Google's big innovation: PageRank was Larry Page's idea for how to rank pages by examining the link structure of the web and prioritizing pages with more inbound links. That specific mechanism quickly broke down when SEO companies began exploiting its structure, but in addition to being gameable, PageRank had another problem: What if the search terms are used in multiple domains? The classic example is the query "python spacing". Am I looking for information about how large an enclosure I need for a captive python, or am I asking about indentation in programming?

So Google, and every other competent search engine, has shifted towards supporting queries in natural language, as well as using contextual information when available, such as the user's search history -- in the "python spacing" example, unless the user is a zookeeper who also writes code, their search history will point to the correct domain.

If you're writing queries as lists of terms that you want matched in pages you're doing it wrong. You'd actually be unhappy with a search engine that gave you exactly that, and you're also artificially reducing the effectiveness of the much better search engine you're using. Try typing questions instead, e.g. "How much space does a 10 foot Python need?" (correct spelling, capitalization and punctuation are not really required, but I use them anyway). This will give the engine more contextual clues about what kind of thing you're actually looking for and you'll get better results.

That said, it should be pointed out that if what you really, really want is "include only these words, exactly as I spelled them", Google will give you that. Just put them in quotation marks.

It's too bad they don't provide numbers, because the numbers are incredible. I occasionally checked the search qps numbers when I worked at Google, just for fun, and... wow. Say what you will about Google, their scale is incredible. The services work so reliably and quickly that you don't often think about what the infrastructure must be like to handle it -- and you can't achieve that kind of scale just by throwing hardware at the problem, either (though lots of hardware is required, obviously). Every layer of the stack is finely-tuned for performance, with both macro optimizations like sophisticated distributed consensus-based eventually-consistent storage and micro optimizations like libraries that squeeze maximum value out of every cycle.

Supporting tens of millions (maybe hundreds of millions now?) of queries per second against a multi-petabyte (maybe exabyte now?) database is an incredible feat of engineering, as is keeping the whole system humming along with near-perfect reliability. There are a lot of damned fine engineers at Google, and "engineer" is absolutely the right word when you're talking about global-scale infrastructure.

One of my first "Google-scale" moments was shortly after I joined in 2011. The global data center status pages had a bug, which was that the field that displayed the aggregate on-line storage (basically all spinning Rust back then, I think; the SSD transition was just about to get under way), was a Java long, a signed 64-bit integer, and it had just wrapped; Google's online storage had exceeded 2^63 bytes. That is a big number. They just updated the code to use a BigInteger instead.

No, but they'll record the punch, then call the police. The recording will be evidence in the subsequent prosecution for assault and battery.

All of the big tech companies incentivize their employees to write up as many patent ideas as possible, and anything that looks remotely plausible gets filed by their patent attorneys. This in no way means the company has any plans to build the thing patented.

Why do they do it then? To build up their "patent warchest". Every company knows that they're going to get sued for patent infringement, because it's just impossible not to. Hamstringing your engineers by having patent attorneys scrutinize everything they're doing to see if it happens to be somewhat close to a thing that someone else patented will drive everyone nuts and drive productivity to zero. And you definitely don't want your engineers searching the patent database themselves... if they stumble across something vaguely close to what they're building or thinking about building, then go ahead with what they were going to do anyway, it's now "willful infringement", eligible for treble damages.

Instead, companies file for patents on everything possible, mostly with no plan whatsoever to build it, so that when they get sued they can then dig through their warchest to find something vaguely related to what the plaintiff builds/does (assuming the plaintiff is a company that builds stuff; patent trolls are a separate issue and require a different strategy), then threaten a countersuit. Then the lawyers get together and craft a cross-licensing agreement, which rarely includes any money changing hands or anyone changing what they're building and selling.

Patent filings like this one aren't news, they're noise, and /.'s editors should know better.

I doubt it. I'd bet it's more of a problem of feature parity with OS X. Even though Windows has backup and restore, it still gets ragged on for not handling device moves or replacements as nicely -- even though the main problem is users and/or app developers not turning it on. I'll bet that first MS offered the feature and left it to users to discover and enable, but hardly anyone did. Then they started nagging people to turn it on, and most still didn't. So now they're turning it on by default.

I saw this same story play out on Android (when I worked there), firsthand. Backup was added to provide feature parity with Apple and to reduce user complaints about lost data. But approximately no one turned it on. In Android there were actually two obstacles, because out of abundant concern for privacy the backup solution required both app developers and users to opt in. User opt-in improved when users were nagged to enable it at setup time, but then they were annoyed that when they restored a backup hardly anything was restored because hardly any app developers opted in. Eventually apps were opted in by default (app devs can still opt out, but most don't) and the feature became somewhat more functional -- except for apps that were broken by it because app developers didn't expect to have their app and its data suddenly appear on a different device.

I had a front row seat to this saga because the component I owned (Android Keystore) was a significant motivator for requiring apps to opt into backup. The problem is that Keystore's core purpose is to provide hardware-backed cryptographic key material which is permanently and irrevocably bound to the device (and is strongly guaranteed to be wiped on factory reset). When an app that uses Keystore keys has its data restored from backup and then tries to load one of its Keystore keys, it gets a null pointer. If the app developer didn't check for null, that turned into a NullPointerException, and if they didn't catch the NPE, their app crashed. Net result: after a restore, most banking and many other apps crashed on startup because one of the first things they do is try to use their keys to authenticate to their servers.

I designed a key backup and restore scheme but my scheme would require app developers to opt into key backup on a per-key basis, at key generation time, because adding any automatic backup/restore solution would have broken the fundamental security property of Keystore. The scheme was moderately complex because it tried very hard to make it impossible for Google to ever access the backed-up secrets, and it relied on some internal server infrastructure whose sole purpose was to make it possible for Google to store data it could not access. That infrastructure was expensive, fragile, high-maintenance and not much used so it was at risk of being turned down because the teams that used it couldn't afford to maintain it. Strongly authenticating the new device and the user before releasing secrets was also tricky. At the end of the day, I never launched the Keystore B&R scheme (though vestiges of it remain visible in the Keystore secure key import scheme, which was designed for B&R but is useful on its own. Specifically, the import format includes a "masking key" field that isn't really useful in the normal import flow, but was crucial to the scheme that kept the secrets impenetrable to Google).

At the end of the day, app developers eventually fixed their apps to deal with being restored, mostly, and forcing users to make a backup/no-backup decision during device setup generated high adoption. Android B&R works fairly well today (except where device OEMs screw it up), though people still complain that the whole system isn't as smooth or as seamless as iOS', I think mostly because Android apps can opt out, but iOS apps can't (AFAIK).

If you pay it off every month, it's not really debt, is it? You never pay any interest, and the only way it translates into actual debt is if you have more expenses than you can cover -- but in that case you'd be reaching for debt of some sort regardless. But with a CC you do get the fraud buffer (the fact that you haven't happened to need it, yet, doesn't mean anything), and you get to delay your payments by about one month, which IMO is really quite nice. I not only get a short interest-free loan, letting me keep my cash in an interest-bearing account (currently about 1%, not a lot but not nothing), but I also have the flexibility to decide which account or accounts to keep my cash in (I actually keep most of it in a couple of brokerage accounts, not a regular bank account; yes, it's still insured by FDIC).

Plus I get 1-5% cash back depending on where I use it.

I realize that The 2-6% I get back (rewards + delayed payment interest) is paid for out of the fees the merchant pays and passes on to us all. I think it would actually be better if merchants were allowed to itemize those fees on my bill, which would discourage use of high-fee cards and change the calculation. With the system as it is, though, I'll absolutely stick with my credit cards.

This is very regional, but if you're talking about populations that speak 3+ languages fluently, it's generally not because they learn them in school.