the main problem with RISC-V is also the main selling point: there is no single owner company behind steering development and making sweeping decisions
how will that pan out over the long term is really unclear and the reality is performance is actually catching up quickly
History tells us that open standards pretty much always beat out proprietary ones in the end.
You cannot buy the company backing RISC-V to take out the competition. And if a RISC-V company stumbles, the ecosystem carries on. But if even one RISC-V company is in the right place at the right time, RISC-V can surge ahead. It is hard to imagine it does not dominate eventually.
I don't agree with history telling us that at all. HDMI, MP3, MPEG, .docx, DirectX, CUDA, I'm sure there are more. History tells us that money wins.
But I also think this is an example of a slight disingenuity in RISC-V being referred to as open-source. It's borrowing the clout of open-source software projects where the end user has the freedom to compile them at home. I can't fabricate a CPU at home, I'm still beholden to whatever patents the manufacturer chooses to license. SiFive have a >billion dollar valuation, for a business based on selling licences.
Those standards are adopted because they work. And they work because someone poured in tons of RnD to make them work. And those people are incentivised to do the RnD because they get paid (patents).
Nowadays nobody will want to work on foundational open source work for free only to enrich everyone else that builds on top of it.
What I see is that you'll get low end chips for embedded applications, because you tend to specifically build and compile programs for things as small as that. You'll also get the large sever and massive super-computer scale systems, because yet again you'll compile code specifically for those systems.
What you're less likely to get is the consumer level PC and Laptop systems, as you'll need one large company to set the standard and others to adhere to it. So you could feasibly compile a program for a certain level of RISCV chip and have it run on many vendors processors. As it is there's several companies trying to push ARM for some sort of high end consumer PCs/Laptops but they all require different OSes and the chips aren't equivalent, so you have to compile software separately for those different platforms.
If it happened, it wasn't in all of Innsbruck. I was there earlier this year and it seems a good chunk of the historical center hasn't been replaced by more modern buildings.
There was some comment here somewhere arguing that 16 characters for a password is too little, but that he used the pattern lock. Looks like it was deleted.
Anyway. The pattern lock in Android provides Log2(389112) =~ 18.57 bits of entropy. This is less than 3 random characters, or 4 lowercase letters, or a decimal PIN digit password of 6 characters.
Granted, you could use mnemonics for long passwords, but how convenient is to input those long passwords?
I wonder why don't they just allow for longer passwords and just use a hash digest when it's too long, rather than just disallowing people from using strong passwords that they will remember. This pushes people to reuse passwords, send them to themselves, and other bad practices.
GrapheneOS supports up to 128 character passwords to support using diceware passphrases. Using a strong passphrase avoids depending on the secure element. A random 6 digit PIN is secure due to the secure element rate limiting. Only a total of 20 attempts are permitted so even a random 4 digit PIN would be fine.
GrapheneOS adds the option to set a 2nd factor PIN for fingerprint unlock to make using a strong passphrase convenient without the downsides of biometric-only unlock.
Pattern lock strongly encouraging using only a tiny subset of the possibilities so it's much worse than your analysis shows. It was removed from GrapheneOS years ago because it's far worse than simply generating and using a random 6 digit PIN despite appearing to be similar. It gives a false sense of security and we didn't want to add support for a duress pattern or random pattern generating alongside those planned features. Built-in random PIN and passphrase generation is still in progress but has been started and will be shipped.
yep, human bias makes 4-digit pins and patterns a lot worse than the theoretical entropy, but still it's a decent starting point
my comment was about the decision of that person who deleted the comment to go for the pattern lock, while/because? 16 chars was supposedly bad for the password (although he/she has a point in that the limitation is annoying and counterproductive)
all of this i reckon was not criticism of GrapheneOS but stock Android, AFAIK grapheneOS's choices are all very sound
>>To make a strong passphrase convenient to use without ruining it with biometric unlock, GrapheneOS adds an optional 2nd factor fingerprint PIN. We reduce the allowed fingerprint attempts from 20 to 5 and failure to enter the correct 2nd factor PIN counts towards it. This enables using 6-8 random diceware words as the main unlock method required in Before First Unlock and fingerprint+PIN using a short PIN for convenience. Using a valid fingerprint prompts to enter the 2nd factor PIN which is needed to complete unlocking the screen and hardware keystore.
Pattern lock isn't exposed to the user afaik because it's insecure.
>I wonder why don't they just allow for longer passwords
They allow up to 128 digit passwords which they changed from AOSP.
I use a long passphrase for primary unlock and it's convenient because you only enter it when you restart.
If you rely on the secure element than 6 digits is fine. A long passphrase ensures you're protected even if the secure element is exploited.
Modern Pixel phones have a TPM-like device that protects against brute-force attacks. Assuming the pattern is non-obvious, an attacker has 20 attempts before the supplementary key material is wiped and the encryption key is lost.
It's theorerically possible to use side channel attacks against the security chip to bypass this, of course, but that requires opening the device and some very precise, damaging operations, assuming the attacker has a known-working side channel attack in the first place.
you don't get the insane profit margins they want without those predatory practices, not in this industry and if you do it's a one-off and not something you can do every fiscal year
probably worth adding some ML filter to it because yeah, most of the bulky stuff in bittorrent is always going to be garbage - a lot like the internet generally, the value is in filtering the good stuff out
there's certainly massive amounts of porn, esp. if you look at active traffic, but perhaps even worse than that is random crap collected for no good reason and "backyard genius" trash content pooled together by the gigabyte
quality and traffic are grossly uncorrelated, so finding stuff is a huge challenge
still worth it because otherwise you have essentially no software advantage over competing architectures (at the time, mainly Motorola 6800 successors and the PDP-11 architecture)
how will that pan out over the long term is really unclear and the reality is performance is actually catching up quickly
reply