4 ms·

There’s something about “translating system calls” that just makes me wary. It’s the kind of thing that could be proven to work for some common cases while fai

There’s something about “translating system calls” that just makes me wary. It’s the kind of thing that could be proven to work for some common cases while failing in mysterious ways for others (not to mention being hard to debug). Generally, there is a gap between what’s documented, what was thought to be true, and what is. At some point they will produce behavior that just doesn’t match what compiled code expects. For how many libraries, applications and combinations thereof will they deal with this? And then there’s maintenance. This is a scary kind of layer to be responsible for; future Microsoft employees will have a hard time doing anything to this layer without risking new misbehavior so we have to trust that they either know what they’re doing or that they won’t touch anything. I’m not saying that they weren’t clever to try this, or that there isn’t a way to pull this off successfully. I do think the odds are against them though. Or maybe, I just missed something about their implementation that makes this a lot less risky than it seems to be.

OneNoteIsFree 10y ago
Have you heard of testing? And have you heard of software verification? Microsoft research is far and away the leader with single person publishing multiple papers in the best conferences- POPL etc. orrying about imaginary Don't worry about imaginary future problesm. Its like me saying- my car is very complex and may crash, I will not drive it. This is how you hold technology back.
- makecheck 10y ago
  This is actually just about the exact opposite of proper testing and verification. The main problem is the idea of running compiled programs unmodified: programs that had an entirely different OS target when they were built. If this is what Microsoft is doing then they’ve invented an environment that could not possibly have been anticipated by those who built the original programs. Anything could happen. And worse, it’s not clear who to send the bug report to when things go wrong.
- quickben 10y ago
  With all due respect, your post looks like a shiny marketing pitch to me. What you call 'imaginary future problem' is everyday for some people. Think three months of work for a team of eight senior system devs per sys call behaving unexpectedly. And tbh, windows was historically far worse than Linux in that area with all the 'bug compatibility' and closeness per version. Yes they can provide a layer for some calls now, it's all shiny and hipster, but it will be cold day in hell before a major bank or big enterprise runs anything serious on it. Maybe in ten years if Microsoft doesnt chop it out by then.
blackoil 10y ago
This isn't meant for productions, so a rare failure scenario shouldn't be catastrophic. Also Windows is inherently designed for such usecase, so maybe it has some reliable process for same.
ketralnis 10y ago
Bryan Cantrill has a wonderful talk about exactly this in Illumos that I recommend at every opportunity https://m.youtube.com/watch?v=hgN8pCMLI2U https://m.youtube.com/watch?v=hgN8pCMLI2U
- ketralnis 10y ago
  Err, I meant https://www.youtube.com/watch?v=TrfD3pC0VSs https://www.youtube.com/watch?v=TrfD3pC0VSs

OneNoteIsFree 10y ago

Have you heard of testing? And have you heard of software verification? Microsoft research is far and away the leader with single person publishing multiple papers in the best conferences- POPL etc. orrying about imaginary Don't worry about imaginary future problesm. Its like me saying- my car is very complex and may crash, I will not drive it. This is how you hold technology back.

makecheck 10y ago
This is actually just about the exact opposite of proper testing and verification. The main problem is the idea of running compiled programs unmodified: programs that had an entirely different OS target when they were built. If this is what Microsoft is doing then they’ve invented an environment that could not possibly have been anticipated by those who built the original programs. Anything could happen. And worse, it’s not clear who to send the bug report to when things go wrong.
quickben 10y ago
With all due respect, your post looks like a shiny marketing pitch to me. What you call 'imaginary future problem' is everyday for some people. Think three months of work for a team of eight senior system devs per sys call behaving unexpectedly. And tbh, windows was historically far worse than Linux in that area with all the 'bug compatibility' and closeness per version. Yes they can provide a layer for some calls now, it's all shiny and hipster, but it will be cold day in hell before a major bank or big enterprise runs anything serious on it. Maybe in ten years if Microsoft doesnt chop it out by then.

blackoil 10y ago

This isn't meant for productions, so a rare failure scenario shouldn't be catastrophic. Also Windows is inherently designed for such usecase, so maybe it has some reliable process for same.

ketralnis 10y ago

Bryan Cantrill has a wonderful talk about exactly this in Illumos that I recommend at every opportunity https://m.youtube.com/watch?v=hgN8pCMLI2U https://m.youtube.com/watch?v=hgN8pCMLI2U

ketralnis 10y ago
Err, I meant https://www.youtube.com/watch?v=TrfD3pC0VSs https://www.youtube.com/watch?v=TrfD3pC0VSs