Building the XNU kernel on macOS Sierra
0xcc.re
0xcc.re
Don't get me wrong, it's great to read how file drivers really work, and read how XNU manages virtual memory, but other than that, it's a pretty crappy drop.
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 :)
I'm curious why Wayland changes things for you. X11 is warty as hell, but that's generally not something visible to the user. I don't go "Eww, they didn't bother framing the graphics message packets properly -- I'm going to use another OS".
I lost count how many times I sat at FOSDEM X room, seeing the improvements that would eventually come (some day).
At the protocol level, X isn't involved that much with the 3D graphics stack anyhow these days. Xorg simply speaks DRI3, which is just a way to marshal file descriptors representing graphics buffers over the connection. It isn't involved in the rendering happening at either end (application and compositor).
As the name says, DRI3 was yet another attempt to improve the whole performance stack on Linux.
As mentioned, I did my share of FOSDEM sessions.
thanks for the laugh
"John Carmack: Its still OpenGL, although we obviously use a D3D-ish API [on the Xbox 360], and CG on the PS3. Its interesting how little of the technology cares what API you're using and what generation of the technology you're on. You've got a small handful of files that care about what API they're on, and millions of lines of code that are agnostic to the platform that they're on."
http://fd.fabiensanglard.net/doom3/pdfs/johnc-interviews.pdf
AAA studios already adopted Metal on their engines, Vulkan only matters on GNU/Linux among those having supported graphics cards.
On Android, it is only available as optional graphics API in 10% of devices available worldwide.
On Windows, it is only supported on legacy Win32, it isn't and it won't be supported on UWP.
On Nintendo Switch, there is the option to use the more lower level API NVN instead.
So laugh at will, lets see which APIs game studios care about.
Genuine question : Do AAA studio really care about metal ? Is gaming on Mac a thing now ?
Gaming on the Mac is a thing to some extent. See Steam for MacOS.
Also Apple's augmented reality is based on Metal, and they had Valve on stage praising it at WWDC, with native support on SteamVR SDK.
Finally, many of the frameworks that made use OpenGL, including the window manager, are now working on top of Metal.
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.
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.
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.
- Tessellation is weird in Metal, as you don't have hull shaders and have to wedge it into the compute pipeline.
- I haven't found a good way to disable multisampling while rendering into a multisample texture, something that is trivial in OpenGL. This can be useful for various effects.
- Switching command encoders is really slow.
- There is no good way I have found to be able to get good timing information inside the app as opposed to the profiler. The info is available on iOS, but not macOS. This is important for telemetry, etc.
Studios are obviously just going to choose the API that's supported on the platforms they're shipping to. Usually there's only one "blessed" API, and so that's the one they pick. It doesn't say anything about the quality of those APIs.
On X there is a mixture of X protocol, 3D stack and the interactions among all possible combinations.
This also reminds me about a cool project I've found, but not had time to test yet; https://github.com/shinh/maloader
Try Linux Mint. The only configuration you will do is to enter your username and password.
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)
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.
Related anecdote: I started a friend of mine on Ubuntu, but she hated all the configuration via endless clicking. She immediately took to Archlinux---there's still configuration, but it's simpler and since it's all text, it's much easier to just read everything on the Archwiki instead of having to follow pictures (or descriptions of pictures).
The majority of devs are happy having a replicate of PDP-11 experience, maybe with twm and tools like xdvi or xv.
Those that try to improve the overall desktop experience closer to other desktop systems, get bashed as needless fluff.
Plenty of material.
On the other hand, linking to some crappy research in a hastily peer "reviewed" journal, with 20 participants and no controls, that satisfies your biases and which you haven't even read except for the abstract is considered epitome of discussion.
By the way, visual studio and intelij idea look the same on all platforms
I have never been as productive as I am now. No more fighting xcode or using outdated core tools.
Apparently tons of people -- at least did.
>No more fighting xcode or using outdated core tools.
Well, if you don't need to use Swift/Obj-C or develop for Mac/iOS (which apparently you don't) then why use XCode at all in the first place?
It will not be true for absolutely all instances (almost nothing is except the laws of physics), but it's just supposed to tell what the most common observed case.
Without stereotypes (a.k.a. generalizations) there's no science and no discussion possible.
You can fault a stereotype for not being representative (if you have different observations or stats or explanation etc.), in which case it's a bad stereotype, but not for being a stereotype.
I know it's technically possible to write a good GUI tool but if some tool doesn't have a fully functional CLI I immediately distrust it.
EDIT: Windows is also a "semi-microkernel" with a microkernel inside of it on the bottom that seems to be used for consistent way of interfacing components more than anything. I'm not sure if it's still in there.
The rest was all new for me, thanks for the information :)
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.
As an example, you can see here how Apple removes whole files and even code in #ifdef sections before throwing it over the wall:
https://opensource.apple.com/source/hfs/hfs-366.50.19/make_o...
Of course you can get a long way accessing a block device directly with FUSE, but ultimately you end up developing a FUSE library, not something you can use within the kernel.
edit: It looks like Safari's reader mode fixes things.
I can't tell if that's a legitimate warning, or it being paranoid about what else is on the site.
Online services says it's clean and I know how to secure my own webserver/services :) https://sitecheck.sucuri.net/results/0xcc.re