Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building the XNU kernel on macOS Sierra

0xcc.re

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Building the XNU kernel on macOS Sierra

#61

Post by pcwalton »

pjmlp wrote: post #59
pcwalton wrote: post #58

Earlier quoted context omitted.

Apple is using Metal because it's a modest improvement over OpenGL (in some areas; it's a regression in others) and, more importantly, their OpenGL implementation is extremely buggy. You haven't said anything about Vulkan vs. Metal, and you can't, because Vulkan is a better API for the reasons I described upthread.

I can't say anything good about Vulkan, because I am not going to buy a new laptop or a Google Pixel just to try it out.

Then please stop saying it's a bad API.

Full disclosure: I have colleagues and friends on the Khronos standards group, and I don't like seeing their work bashed without specific technical reasons.

Re: Building the XNU kernel on macOS Sierra

#62

Post by pcwalton »

nickpsecurity wrote: post #49
mikalv wrote: post #7

Earlier quoted context omitted.

Yea personally I'm mostly fascinated with the semi microkernel architecture. I don't really mind that the rest is closed. And yea, I've suspected they lost some good people after seeing all the new security issues in the kernel the past years. If only wayland was more mature, and the Linux world would have put down X11 once and for all, I would be back on Linux a long time ago :)

The merging of Mach with UNIX was a mistake given it was one of the slowest, over-complicated microkernels. Far as I'm aware, they'd prefer to remove Mach but it's a big job at this point that might affect their ecosystem a lot. If you are interested in open microkernels, I encourage you to look into L4 family (eg OCL4 or OKL4) since they're far more advanced than Mach-based designs. Minix 3 does one with NetBSD user…

Mach is fine. The IPC primitives it exposes are a lot more straightforward than Unix sockets. The performance issues everyone talked about in the '80s are not really problems anymore in 2017.

L4's send/recv context switch trick is great until you get to SMP, at which point its performance necessarily moves closer to that of traditional microkernels like Mach.

Re: Building the XNU kernel on macOS Sierra

#64

Post by mikalv »

valarauca1 wrote: post #4
dcow wrote: post #3

I'm sorry but I stopped reading because you've chosen to break lines mid-word (reading on mobile). Justified text would be a lot easier to read. edit: It looks like Safari's reader mode fixes things.

I thought this was a petty HN UI comment but no. Readying the post is painful nearly ever other line ends in a split word on mobile.

I think I managed to fix it :)

Re: Building the XNU kernel on macOS Sierra

#65

Post by pjmlp »

pcwalton wrote: post #61
pjmlp wrote: post #59

Earlier quoted context omitted.

I can't say anything good about Vulkan, because I am not going to buy a new laptop or a Google Pixel just to try it out.

Then please stop saying it's a bad API. Full disclosure: I have colleagues and friends on the Khronos standards group, and I don't like seeing their work bashed without specific technical reasons.

Where have I said it is a bad API?

I have said it has insignificant market share and that share won't get better outside GNU/Linux for the foreseeable future.

That has nothing to do with quality.

Re: Building the XNU kernel on macOS Sierra

#66

Post by dcow »

valarauca1 wrote: post #4
dcow wrote: post #3

I'm sorry but I stopped reading because you've chosen to break lines mid-word (reading on mobile). Justified text would be a lot easier to read. edit: It looks like Safari's reader mode fixes things.

I thought this was a petty HN UI comment but no. Readying the post is painful nearly ever other line ends in a split word on mobile.

I really tried to read it before whining. Glad to see it's much more readable now.

Re: Building the XNU kernel on macOS Sierra

#67

Post by dcow »

mikalv wrote: post #63
dcow wrote: post #3

I'm sorry but I stopped reading because you've chosen to break lines mid-word (reading on mobile). Justified text would be a lot easier to read. edit: It looks like Safari's reader mode fixes things.

I think I managed to fix it :)

Looking good, thanks!

Re: Building the XNU kernel on macOS Sierra

#68

Post by unixhero »

nickpsecurity wrote: post #51
unixhero wrote: post #25

Earlier quoted context omitted.

Yeah. Linux is not like that any more. Try Linux Mint. The only configuration you will do is to enter your username and password.

And then again when their site gets subverted and you have to reinstall since you might have a rootkitted binary. I loved Mint for its incredible usability. Just can't recommend a supplier whose security was that bad.

Nah. You can't hold a 'maintainer transgression' which happened two years ago against them forever.

They have indeed implemented solid checks and offer a Shaxxx-sum file for every iso file they publish. Not only that, bt publicly "soul searched" and went to great lenghts to assure the community and its users that such mistakes would not be repeated. Now verifying the authenticity of the iso file actively encouraged, on the download page.

They made a mistake, took solid steps to improve, and the show has moved on. You should too, instead of smearing the project far far down the line. (I'm being retorical, I know)

Re: Building the XNU kernel on macOS Sierra

#69

Post by nickpsecurity »

unixhero wrote: post #68
nickpsecurity wrote: post #51

Earlier quoted context omitted.

And then again when their site gets subverted and you have to reinstall since you might have a rootkitted binary. I loved Mint for its incredible usability. Just can't recommend a supplier whose security was that bad.

Nah. You can't hold a 'maintainer transgression' which happened two years ago against them forever. They have indeed implemented solid checks and offer a Shaxxx-sum file for every iso file they publish. Not only that, bt publicly "soul searched" and went to great lenghts to assure the community and its users that such mistakes would not be repeated. Now verifying the authenticity of the iso file actively encouraged,…

The project's security sucked across the board. They didn't care or know how to do it. One hacker here even appeared to hack them in mid-discussion and post database credentials that showed they were using defaults. They then implemented a mitigation after bad press and soul searching. The thing I'm doing isn't smearing the project: it's letting people know not to trust its security without 3rd party verification (esp pen tests). That's because (a) it's a sane default for any project and (b) this one failed hard on the basics at least once.

So, I advise caution until I see a 3rd party evaluation showing their security is good now. You apparently followed them carefully. Did any security professionals look at their site/db/whatever after the fixes and give independent confirmation? That's all I'd need to stop reminding people of this.

Post reply on HN