samueldr

Thanks for taking the quote of context. It's not like the sentence as a whole could ever have any more meaning than a snippet of it.

As I clearly stated, what is user-controlled is the sideband channel to debug the system on consumer hardware. The sideband channel under the current implementation of Cr50 is entirely user-controlled. This is a fact, as the end-user of the machine has control over the sideband channel.

I did not state any judgement about the GSC itself and its firmware.

And please don't start spreading FUD around hypotheticals of updates changing that. Yes it is possible. But a lot else and worse is possible under that scenario, so it serves no purpose but to spread FUD. And is still irrelevant to the content of the previous comment.

I am asking you, please do not ever derail what I say with FUD or out-of-context quotes ever again.

Thank you.

Right click the generated map, turns out there's a menu.

Conceptually, it needs to take in account the type of date it handles. The question to ask is “does it matter when in the week or a month a date is selected?” or similar.

Under these considerations, I can say that for a "well known" date, like a birthday, or an expiration date, where the context of the calendar doesn't matter, it's not needed, and probably undesirable. (Under these contexts I would use bare selects/inputs with one for each of YYYY/MM/DD.)

For an appointment, or a time span? Date pickers are useful. “Which days are mondays?” “I want to book from a monday to the friday the next week.” Raw controls won't provide the context to help the user.

I feel the ones you fight against are more than likely those where you already are aware of a precise moment, in the first scenario. The others are more likely to leave no impression if well done.

With that said: Always de-compose the date picker in their discrete parts that a user can use. Make the picker fill these.

I will wait for an official answer from a Google rep. There is too much at stake to guesstimate on vague phrasing.

And still, losing google docs document sharing, and calendar, on the e-mail address identifier which will stay my valid and primary one is a hostile move, plain and simple.

I will wait for an official answer from a Google rep. There is too much at stake to guesstimate on vague phrasing.

And still, losing google docs document sharing, and calendar, on the e-mail address identifier which will stay my valid and primary one is a hostile move, plain and simple.

Any idea if they'll make a "gmail.com" account migration utility down the line? This is extremely concerning for Play store purchases, and anything non-email attached to the "google apps for your domain" account, like YouTube.

I figure all play store purchases and similar content are now taken hostage.

Are there any ways to migrate those licenses to a "google account"? Or am I being forced to pay to keep using licenses I already paid for?

Oh, and what about my YouTube channel?

Only thing missing is indexing of branches and forks.

My main use case for GitHub search is identifying provenance of misc. changes in vendor source code tarballs for e.g. Android kernel releases. It's hard, but sometimes possible to rehydrate most of the existing commits through cherry-picks and careful rebases.

The biggest problem with the lack of indexing branches and forks is that sometimes vendors makes releases through branches, or that sometimes repos of interests are forks of e.g. `torvalds/linux`.

Hopefully we can see those being indexed in the future.

I'm also curious: has the plan to drop "less active" repos from the index gone through? Has anything changed?