hugelgupf

You should be able to disable write protection on the firmware flash using a suzyq cable to enable closed case debugging as well, and from there disable write protection. The screw is not the only way

I don't really get their headline.

Google extended the AUE to 8 years. They're complaining that most Chromebooks only have 4 years of software life left. Are they buying devices released 4 years ago? Or refurbished devices?

[twitter OP] This is true. Appears once a day or so, you hit OK. Sometimes during a show you're watching, sometimes while it starts up. Don't know if it becomes blocking some day...

[OP here] I filed a thing for them and this person will get it in front of the right people. I have more faith in that more than generic Apple support anyway.

Why on earth did he agree to those FBI interviews where he admitted all this?

It is a failure, but not of the HTTP service. It's a failure of the RPC call.

404 means "this API doesn't exist", not "the API exists but it returns an error"

Brain fog, intestinal inflammation. Sounds so very familiar.

Do you have research notes, on methodology and things tried? I'm now very curious for myself.

That sounds much more attainable than what the blog post suggested - sorry if I took that the wrong way!

Given what I just read about IncludeOS (I'm not really familiar), it feels like implementing as much of musl as possible is probably the best you can do compatibility wise. There are going to be a lot of Linux features simply incompatible with includeOS, so claiming that 400 syscalls will be implemented is unlikely.

That said - why do you have to get musl compatibility by implementing the Linux syscalls? Is contributing to musl an option?

The number of system calls says close to nothing of the actual API surface present here. It's a poor measure. What actually matters is: what can I run?

That said, 42 is not enough to run a lot of applications.

It'll be interesting to get to the point where they can run a language's runtime or unit tests.

Take it from someone who worked on gVisor: this is gonna take a long time, and eventually you'll end up with a system that's just Linux. You'll end up either being bug-for-bug compatible, which means bringing in loads of compatibility code and architecting your kernel just like Linux, or you'll end up having to change applications (and then you're not all that compatible anymore).

Neither are fun or sustainable compatibility stories. You'd probably actually get Linux apps to work on a random OS faster & nicer by porting gVisor.

> Moreover, since implementing a system call is typically pretty simple [...]

You're in for a fun ride, folks.

Do you have a source for the Norwegians?