This does look like a hit job. The spy stuff is ultimately meaningless and a smoke screen and may even be offered up to create plausible deniability. My take is that Dems/Biden + China Hawk Rs + decel crowd/Dario wanted export control and closed models. Jensen and Trump took a different view. Now that Dems have the Congress again, it's going to be non-stop hearings and investigations in the same spirit as the TikTok CEO with all the "Are you a commie?" questions. So the spy is offered as an explanation; nobody evaded export controls and nobody is a commie. The 2nd unrelated affair just points to an op to oust him.
Such a pointless criticism. Apple and Android don't make end-user installable OSes. What good will going to apple.com/os/ios do? Do you see a "download" button? By design, installing an OS on a phone is more involved than buying a phone from a store. Putting more screenshots on the website isn't going to change that.
To me, the approach of product management makes a lot of sense. For example with linux and gaming, some of the gamers can surely be reached with a nice website, a streamlined installer etc, initiating a conversion from Windows. However, what really boosted Linux in the gaming space is Steam's involvement - first by creating an easy to use product out of Wine (Proton) and a great bundle with the Steam client, and then by releasing the Steam Deck, which has Proton preinstalled and as default. This created an incentive not just on the gamer side, but on the developer side as well.
I want a similar thing for GrapheneOS. I think the current project and website is not just fine, it's more than enough the way it is. Where it needs more energy is reaching users via b2b agreements - like having phone manufacturer support for GrapheneOS, and even better, Graphene preinstall offerings, preferably in a wide price level. Murena, for example, is one that's on the right track with their similar thing. I want this for GrapheneOS as well.
I guess the TL;DR is: they don't need to target the end user better, they need to find businesses as partners.
Thanks for taking the time to actually walk through your idea - it does make sense and you did a good job of explaining it to me.
I would say it's still a bit more of a slower growth approach, but that can be fine. To be clear, I don't really have a dog in the fight, I was just questioning if faster growth is what Graphene wants versus an approach like you're describing. Both can be viable for growing, but even with your linux/Steam example, it's not like linux has taken the world by storm - it's still at ~4% "market share" (and that's even among Steam users). It's still very niche, really only used by gamers and coders.
But I think we're talking past each other, or at least with different assumed goals. My suggestion of showing features and having a more broadly appealing website assumes GrapheneOS wants to some day be on 30%+ of phones in the US (potentially supplanting Android). And I just don't see how you get there with the website as it currently is.
You know what, indeed, when reading your point like that, I agree. From my POV, GrapheneOS is not looking great as a product. Which is exactly what you miss as well - looking at the website, and its inadequacy as promotional material.
I never said putting screenshots on the website will make it easier to install an OS. Not sure how you reached that conclusion. I said it would lead to more people being likely to even want to try/install the OS. Those are two entirely different things.
It's also wild, and worth revisiting, that you're OK with installing an OS being more involved than buying a new phone. I can see what an app looks like and install it on my phone all in about 30 seconds. Obviously an OS is different, but that's the download/install experience the average customer is used to, and it would benefit Graphene to get closer to that user experience if they want more users (which was what I was calling into question).
I'm really struggling to understand what your point is here (ironic considering you're saying my criticism is pointless). Are you suggesting that adding screenshots or videos to the website would somehow be a bad thing?
Because the way I see it there's two options here. Either adding more visuals to show off the software would:
1) help or be neutral, in which case my criticism is not pointless, or it would
2 somehow be a negative (I fail to see how) and that's why you're chirping back
The OS looks like AOSP. It's not different in any way. They used to have some images in the past of the homescreen with the launcher and stock app icons, but it likely doesn't help much. They are not in the business of endorsing specific apps, so more elaborate images are out of the question. The delta that GrapheneOS adds over AOSP is under the hood, not visual.
> The delta that GrapheneOS adds over AOSP is under the hood, not visual.
Have you ever used it? Yes while the OS looks like AOSP, there is Vanadium (its own browser), its own Messages (SMS) app, its own App Store, its own Camera, its own PDF Viewer, an Info app to view changelogs and an Auditor app.
Plenty to show off. And they're working hard on newer, better polished apps, so the visual/feature delta will only increase.
Yes, I use it. The apps, for the most part, aren't tied to the OS. You can get the apps on the play store or github. Vanadium is a chromium fork that is tied to the OS and not shipped separately.
It doesn't have much to do with this CVE, but if you're trying to sell to the US government, it will often be a requirement, which means that a company making money from those sales will not easily be able to move to a distro without that certification.
It's about using a certified cryptography implementation. Presumably RHEL has such a certification, while Debian has a compliant but uncertified implementation.
This isn't relevant to the CVE, but counters the claim that Debian is always a suitable choice of distribution.
Shield is a 10 year old device at this point. It's essentially the 2017 hw that they've refreshed a couple of times with minor changes. Wait for the actual shield next for proper support.
Yes, there is no point in grading homework or essays. This has been largely true in India and China anyway, and the US will have to move to similar model of standardized tests and in person exams. Universities are anyway proxies for IQ filtering. It is perhaps impolite to say so explicitly in the west, but people will have to confront that.
Maybe for "soft" subjects like History and Philosophy, where almost nobody who does those courses actually becomes a historian or a philosopher... But there are plenty of subjects where you actually do learn things that are useful beyond university. Engineering, law, medicine, chemistry, etc.
It's describing a different type of parallelism - pipeline parallelism. The network is laid out spatially on the wafer in CB's case. So weights are stationary and activations flow. A GPU is going to process the network one layer at a time. GPUs also use other types of parallelism (tensor and expert mainly in inference). Pipeline parallelism doesn't make much sense on a GPU for inference.
I think the point is they need several wafers to fit the model. Data parallelism between requires too much bandwidth (they only have so much edge real estate for io) so you have to do pipeline parallelism with say one layer per wafer. No one does it on gpu unless you can’t fit the model in one fast network domain (which is 72 GPUs nowadays for Nvidia). There is a Dwarkesh episode from like two months ago that explains this reasonably accurately.
The reason 2D grids work well is because you can split tensor axes along whatever dim you want across PEs (batch, sequence, hidden, etc.). And your per PE code is relatively simple. It's of the type : get data from neighbor, compute my subtensor, send to neighbor. And you can implement broadcasts and reductions along any axis.
My guess is it is more like the opposite. They distribute spares evenly along every array in every dimension, so that there are always the same number of selected and unselected cores in each core-set.
With flexible addressing and bus-linking, along any set-line. So configuration happens the same way, with the same efficiency, regardless of whether any of the unselected elements are failed or not. As long as failures don't exceed the unselected-elements per element-array-set number.
And that number of unselected cores per element-array-set, is chosen to put wafer yields where they want them.
Trading a generous fixed wafer under-utilization for high yields, uniform configuration and processing efficiency, despite variable element failures.
No, I think this is a valid threat model and a good rebuttal. The evil maid steals the original laptop, replaces it with a second laptop with a look-alike PIN entry screen without an attestation. You enter your PIN, it is transmitted to the evil maid with the first laptop, and your data is unlocked. You would notice, but your data would be exposed.
Now, to be clear, I don't think this negates TPM-sealed disk encryption or TPM-and-PIN sealed disk encryption; they're still meaningfully better than the alternatives (with a passphrase alone, your data is already compromised regardless in this invented scenario, and all scenarios are equally variable to the swiss-cheesiness of UEFI firmware unless it is replaced). But it is a valid model.
What does it matter if it doesn't unlock the disk? It's a different device with a logger. The purpose of the maid is to be evil and steal your pin. The maid has your real device. The only way to prevent this is by you authenticating the device before you enter anything. Look at the heads project (https://github.com/linuxboot/heads).
reply