41–50 of 296 posts
Earlier quoted context omitted.
It's weird in my later 20s I started doing this, writing homophones. I at least get my then/their/effect right still.
I think this mostly happens to native English speakers for some unimaginable reason. I don't remember ever making this mistake (but do remember plenty others to make up for it), and can't imagine myself doing it. Yet it happens to native speakers all the time.
Earlier quoted context omitted.
The bad thing about Fuchsiais that it's a Google product. They may decide to kill it next week and switch to XNU or symbian or templeos and no one would be surprised.
That’s fine as long as it’s open source and a self-contained local piece of software (as Fuchsia is). The problem with Google killing products is that they’re closed source and/or require huge server resources and/or ML models.
But those write-ups were years ago and there hasn't been new reviews with much UI focus since then.
Earlier quoted context omitted.
"How insecure" a surprising conclusion based on a single exploit.
If you read the article it mentions that ASLR doesn't work, and it's treated as a "known bug".
The people who work on fuchsia are very good engineers - I’ve worked with many of them in person. But the project itself has always been a staff retention project. It only existed to keep said engineers from going to a competitor. I don’t know how any understanding of fuchsia is possible without this crucial fact
As a research project to inform design design, as a long term bet and sure, for staff retention.
You have more insight, but it's sort of hard for me to see even Google put that many millions into an OS and, more importantly, put it into production usage on actual hardware (Nest) if that were the case.
One factor here is that Fuchsia is in direct competition with both Android and Chrome OS.
Maligning it as just a staff retention project might serve those teams quite well... either as a coping mechanism or as a political tool to kill it off.
Earlier quoted context omitted.
I think this mostly happens to native English speakers for some unimaginable reason. I don't remember ever making this mistake (but do remember plenty others to make up for it), and can't imagine myself doing it. Yet it happens to native speakers all the time.
I'm not native and I absolutely do this. 500 grams of flower...
The people who work on fuchsia are very good engineers - I’ve worked with many of them in person. But the project itself has always been a staff retention project. It only existed to keep said engineers from going to a competitor. I don’t know how any understanding of fuchsia is possible without this crucial fact
Earlier quoted context omitted.
That’s fine as long as it’s open source and a self-contained local piece of software (as Fuchsia is). The problem with Google killing products is that they’re closed source and/or require huge server resources and/or ML models.
From what I've read Fuschia is not at all self-contained. The UI is fully driven by and targeted towards Google the search and ecosystem. But those write-ups were years ago and there hasn't been new reviews with much UI focus since then.
Earlier quoted context omitted.
Not necessarily. The core idea of capabilities is more like having a URL to a Web page. Using the URL (the capability), you can access the contents of the page. Inside the contents, you can possibly find other URLs (more privileges granted to you). But the URL happens to be something like an UUID, or a short link; looking at it, you cannot derive another URL (discover another "capability", not granted to you). In oth…
Interesting. Is this in practice implemented as just capabilities being large numbers so it's impractical to guess them, or does the kernel have a table with all of a process's capabilities and when a message is sent to a process with capabilities the kernel adds them to the table? That is -- are capabilities just pieces of data in a message you can detect and try to use, or do they have to be added explicitly to a m…
It uses a couple of techniques, like wide/tagged pointers, object ids, and a special hardware managed bit to track illegal modifications.
If I had to hazard a guess, those object ids are probably useful for general capability systems.
I think apple (maybe as just an arm feature?) can do encrypted pointers, with a per application key tracked by the kernel.
Earlier quoted context omitted.
If you read the article it mentions that ASLR doesn't work, and it's treated as a "known bug".
Kernel ASLR. User-space has ASLR enabled and working, in addition to shadow stacks and a number of other hardening techniques.