(Not to mention that, if I understood it correctly, Linux currently doesn't even support the keyboard, and is otherwise probably in its usual desktop mode of "WLAN, Sound, or functioning sleep – choose any two".
https://news.ycombinator.com/item?id=12820490
That said, the kernel developers working on Mac hardware support aren't Apple haters. We're fans. I also don't share the "not for professionals" criticism that was widely directed at the new MacBook Pro fully: E.g. as stated in the article, the four Thunderbolt ports are interesting for HPC applications as you can build a portable compute cluster with up to five fully-meshed high-speed networked nodes. If that's not professional I don't know what is.
Can you elaborate on what you mean by that? Are you implying a MacBook cluster is an effective HPC platform?
Or let's say you want to quickly set up a Hadoop cluster to crunch some data.
Five machines is certainly small as HPC clusters go, and in reality you'll probably have to cap this to four machines because you need one port to attach to a power socket if you need the cluster for more than 2-3 hours. Nevertheless the 4x 40 GBit/s Thunderbolt ports offer some really interesting possibilities, and I'm not aware of any other portable machine that has this right now.
Also, the Alpine Ridge controllers are attached with PCIe 3.0 4x lanes, that's 31.504 GBit/s, so you can't exhaust the available bandwidth fully.
It is perhaps too early to wave goodbye once and for all to that coalition, but it does seem like some of the design directions that Apple has taken have drifted away from that user base.
That said, this war on the professional and creative class of users began sometime ago - I think the introduction of Final Cut X was the first salvo, while the platform has significantly evolved from the first couple of problematic releases, I personally know some who considered the product a literal betrayal and abandoned ship to Premiere Pro or AVID.
I sense Microsoft is attempting to reassemble that coalition with their offerings, namely the Surface line (especially that gorgeous looking Surface Studio) and the introduction of Bash on Windows, which while still quite limited in its functionality, can be a seen as a step.
I really like my MBP 2013 (NVIDIA GPU) and I guess I am going to keep it a while longer.
Quickly jotted down my own progress as a user http://williamedwardscoder.tumblr.com/post/154376389528/linu...
Really appreciate people making this stuff work, and hope I can use my retina MBP in the long run.
https://github.com/libyal/libfvde/wiki
It's experimental though. Better back up your data.
I'd recommend to create a partition for ZFS and move data there that you want to use on both OSes, or outright install Linux on a zpool and mount that on macOS. This has worked remarkably well for me, even with lz4 compression and all the other great features. Layer ZFS on TrueCrypt if you need encryption, I wrote a howto a while ago but never had the time to update it:
https://github.com/zfsonlinux/pkg-zfs/wiki/Dual-booting-OS-X...
[edit] and this is with any distro, perhaps with more or less setup work
The other problem for Linux I have encountered recently that burned through my free time was updateing the bios, there are no bios updates with Linux installers, which is annoying because the bios is update is OS agnostic. I had to create a bootable USB drive from a windows program (luckily I have a Windows PC for work) and boot from that. But the how-to guide from HP was lacking in details, and on one PC the program doesn't allow me to create the drive on one PC for use on another, so no bios update there.
The problems I have with Linux never seem to be to do with Linux, it is almost always hardware manufacturers being obstinate and refusing to share their toys with other adults.
I also don't plan to purchase any brand new Apple hardware. I will only adopt Apple hardware late (and used) and will only run OS X if absolutely necessary for some reason.
AMD have demonstrated that trying to do the right thing will get you shit from the maintainers and abuse from bystanders, who will then go and buy Nvidia because it gets a better frame rate.
Having a driver is good, but putting it in-kernel is bad if the kernel devs can't read it and fix it.
That has been the case for a decade or so now. 95% is not enough (for non-tinkerers)
For me, major distributions work out of the box. For example, with my T430s, everything works, including the fingerprint reader and WWAN.
I don't understand why would anyone not open-source their drivers?
What's NVIDIA's secret sauce? Being able to build great silicon.
What's Intel's secret sauce? Being able to build great silicon.
What's Samsung's secret sauce? Being able to put together great silicon.
So let's say tomorrow Nvidia open-sources all their drivers?
So now you know that which registers do you use to shade what. So now what's AMD going to do? Copy the interface?
It's already copied. Most users use standard OpenGL/DirectX to communicate with their board.
I mean look at Intel. You practically know what's what there. You can make an OS on (at least older) Intel chips without drivers.
Did it help anyone compete?
OK, so the question is upstream. Why would Qualcomm, ARM, or any upstream care about people finding out the interface to their hardware?
What secrets are there in the drivers?
As I understand things (which I'm clearly not an expert at all), CPU opcode is like an ABI,
put this value into register A, this value into register B, and a magic opcode into register C,
and poof, the register D contains the value of A+B.
A driver will say that you put int X into memory point A, Y into memory point A+1, and call function C with argument of A and D will contain the multiplied number.
So how does #2 protect IP over #1?
Let's also say your hardware implements g, h and i, but doesn't wire them together yet. So, your driver's code calls the three functions.
Unknown to you, the trick to use that decomposition is patented. if you release your driver's source code, you make it easier for the patent holder to figure out that you are violating their patent (your programmers might even have made it patently obvious by mentioning the paper describing the trick in a comment)
Unlikely? Maybe, but the way patents are written, who knows? For an almost random example, I searched for "driver code and hardware patents". The first link I clicked was https://www.google.ch/patents/US20090006831. Reading that, I wouldn't know what driver would _not_ infringe on it.
Also, there are many patents on ways to move data around efficiently. Avoiding all of them while still writing a performant driver at not be possible.
On the other hand it also seems reasonable that a compiler for e.g. NVIDIA's hardware might be hard to re-target to another vendor's hardware while retaining the same advantage.
NVidia's defining characteristic has been designing good drivers.
Even when they've been behind ATI/AMD in hardware, they've been ahead in driver stability and performance. Especially on Linux where they largely own the CG/post/design market (which mostly uses Linux workstations) and they are the only GPU vendor that has somehow squeezed Windows-competitive performance out of Xorg.
This. When shopping for discrete video cards, I no longer look at AMD's offerings because I'm not willing to fight with their driver, fret over whether or not I should apply updates, etc.
First, read this: http://www.gamedev.net/topic/666419-what-are-your-opinions-o...
So basically, most 3D applications and games are broken to a certain degree. Both NVIDIA and AMD invested quite a lot resources into making those applications run at acceptable level and not looking broken.
Now, when you figure out how to unbroke something and put it into fast path, your competitor can lift that easily into their driver. Neither of these players want that.
The good news is, that DX12/Vulkan/Metal have quite a different approach, they don't have complicated state machine and validation in the driver, making the driver simpler and these workarounds unnecessary. If everything goes well, we may see drivers for these stacks.
Microsoft has a lot of resources to incentivize hardware manufacturers to go to great lengths to make sure their drivers work well with Windows. No organization connected with "Desktop Linux" has that.
the reason Linux drivers are a "mess" is that the hardware they are trying to support are a mess, and said mess is papered over in Windows by the OEM drivers.