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.
I wonder if it will have proper CCD (Case Closed Debugging)[0] support.
With CCD, you are pretty much free to mess around with the "BIOS" of the machine, without fear of being put in a bad situation.
It also provides a serial terminal to the "AP" (application processor), e.g. available to the OS.
In other words, the Cr50 provides a controlled and user-controlled (but not user-owned) sideband channel to debug the system, even on consumer hardware.
Why user-controlled? Because it requires asserting presence to "Open", which with the design of ChromeOS basically requires being the owner of the device. Why not user-owned? For official ChromeOS devices, AFAIK that firmware cannot be replaced by a user with their own builds.
I can't find a proper citation, but rounding is undefined.
The recommended guideline[0] is to round to the nearest 5¢.
This article from 2013 is my closest citation to "undefined behaviour"[1]
> These guidelines are only a suggestion though and there is currently no law that specifies how retailers must round.
I don't know since ~2013 if anything has been decided to make those guidelines "law". I couldn't find anything quickly in the SEO cesspool that is modern web search.
The author is likely Canadian given their current biography snippet.
There were Radio Shacks in Canada, before they ended up being renamed The Source in 2004[0]. So in 2009, the year cited in the article, they would have gone to "The Source", but likely still thought of it as Radio Shack, the old name of the chain.
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.
You might want to look around the Pinephone and Pinephone Pro communities. Both phones use the EG25-G modem, chosen for better worldwide band availabilities, rather than splitting the Pinephone in "EU" and "NA" batches.
Users also are working on providing a mostly liberated firmware for the modem:
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.
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?
Thinking about situations [...]
> where this is objectively bad
Thinking here about a smartphone. Note that I'm explaining the current state of things, I am *not* excusing the state of things.
Directly for end-users, generally no real scenario where it's bad as long as they can enroll their own keys in a safe fashion preventing evil-maid type attacks.
Tangentially for end-users, locked devices are easier to make worthless for thieves. FRP on Android, or whatever Apple does, when it's locked to a user account even when reset. This is one thing that would become harder to implement when the root of trust can be manipulated on the device.
Then there's supply chain integrity for OEMs. This is the reason some android vendors only allow unlocking when attached to an online account after a delay (e.g. xiaomi). Some unscrupulous vendors would open the box, replace the system image with a malware-ridden system image, and sell those to end-users.
Finally, there's somewhat a case for DRM and similar uses. The current implementations are built on the current "security" model, where it's security for the businesses first, then security for end-users last.
Still, I agree wholeheartedly that users should be in control of the root of trust, in a way that does not reduce their abilities to use their owned devices. Add to that that standards-based boot should be used. All the time. All devices.
I can't say for your particular model, since you didn't list it, but there is generally a trade-off: the arrow keys make the keyboard area larger and less "squared" (rectangled) as they will protrude from the bottom of the keyboard.
This, in turn, is a trade-off for manufacturing. It will increase the cost of everything slightly. The keyboard unit itself as it will be larger, maye be harder to produce. Machining or producing the chassis now requires accounting for an additional cut.
This is all solvable, yes. Though it is harder for smaller scale productions. It is likely they are working with vendors that, themselves, only have "entirely rectangular" keyboards as this is what the market ends up wanting for cost reasons.
This is a "normal 'GNU/Linux' distro" (well if NixOS is normal for you).
Just like NixOS doesn't prescribe a user interface, it is left to the end-user to choose what they want to run.
As such, this is meant to allow you to run the "mobile first" desktop environments like Phosh and Plasma Mobile. As many other non-Android Mobile Linux distributions do.
So to answer more succintly: no, it doesn't run Android. Yes, some other UI, at the end-user's choice.
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.