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.

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.

[0] https://chromium.googlesource.com/chromiumos/platform/ec/+/c...

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.

[0] https://www.canada.ca/en/revenue-agency/programs/about-canad... [1] https://cba.ca/phasing-out-the-penny-in-canada

While it won't provide "at rest" detection, Apple has released an app for Android devices.

- https://play.google.com/store/apps/details?id=com.apple.trac...

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

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.

[0] https://en.wikipedia.org/wiki/The_Source_(retailer)

Just noting, using Nix it is also possible to build an actual real deal Android image using Robotnix:

- https://github.com/danielfullmer/robotnix/

This is different from a non-Android Linux on Mobile devices, which is what Mobile NixOS aims to achieve :).

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:

- https://github.com/Biktorgj/pinephone_modem_sdk

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?

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.

Yes.

Anyone with the hardware is welcome to contribute to nixos-hardware!

Even "no-op empty configs" are good imo as they show "there's no magic sauce needed".

Short answer "not really".

While it could be used to recover the phone, it requires a "programmer" program, which is signed by the vendor (Google, here) that hasn't been leaked.

Or, really, I should say that these programs should be made available as "software rights to repair".

---

Some reading:

https://alephsecurity.com/2018/01/22/qualcomm-edl-1/

A more up-to-date open source tool:

https://github.com/bkerler/edl/

EDIT:

see also this sibling (to you) reply:

- https://news.ycombinator.com/item?id=28545937

For non-musl (so GNU libc), it's the awkwardly named gnu64. To test with the classic test package "hello":

     $ nix-build '<nixpkgs>' -A pkgsCross.gnu64.hello

All "pkgsCross" systems are found in https://github.com/NixOS/nixpkgs/blob/master/lib/systems/exa...

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.

Again you're right. Though the problem is that NixOS itself still doesn't have the answer for this question. So it's less about "Why Mobile NixOS?" and more "Why NixOS?".

Mobile NixOS is intended to be strictly a supserset composed on top of NixOS. So the question should be answered the same, except you add "for your mobile devices" at the end.

BTW, one thing I don't want to see happen to any of these distros is for PinePhone to be the only actually solid device.

I share the same concern. I've been elevating the different platforms about equally. This is why there's so many "unfinished" ports. They are approximatively at equal support, but the crucial thing is that I helps me validate assumptions. I wrote a bit about that on my personal blog[0].

In fact, it's caused some "concern" about the viability of Mobile NixOS as the Pinephone isn't any more "well supported" than other platforms, which means there's work to do still :).

0: https://samuel.dionne-riel.com/blog/2020/04/24/mobile-nixos-...

Hi, author/lead dev here, I'll be glad to answer questions if any, but please ask at the root and not directly to this comment.

I'm not using NixOS because even though it officially supports Raspberry Pi 3, I have not found it to be stable on that platform.

I'm curious to hear more details about issues you might have been facing.

You can hit me us/me up on the Matrix channel[0] for "NixOS on ARM", tag me (@samueldr) on the Discourse[1], open an issue[2] if there's something actionable (and you didn't already), or I guess a reply here could do too, if you want.

0: https://matrix.to/#/#nixos-on-arm:nixos.org

1: https://discourse.nixos.org/

2: https://github.com/NixOS/Nixpkgs/issues

You might be interested in: https://github.com/NixOS/mobile-nixos/pull/361

Though you might want to ask around for your particular use case. While basic support (it boots) is right around the corner, it's probably not yet at a point where it'll be nice to use.

You're right. The website right now was written for existing NixOS users.

They're also the initial target demographics, if only because this is a limited amount of developers in what is a cross-section of two niches: Non-Android Mobile Linux and NixOS users.

But you're totally right. Once it's "ready enough" for any end-user, we'd want to make it clear "why Mobile NixOS rather than another Non-Android Mobile Linux?"