Metal isn't new, it's older than Vulkan, and by some metrics I would consider it better.
For one, the learning curve is much smoother: you can get something up on screen quickly, but only later discover the advanced features like argument buffers, manual hazard tracking, etc.
We are talking 4 years old (3 for desktop) years old vs 2 years old, you're kidding yourself if you think either is established by virtue of being old vs new. That comparison was only fair with OpenGl.
Erm, not really. I have implemented a reasonably serious PBR renderer in Vulkan on Mac on top of MoltenVK, and the C API is not at all an obstacle. Swift/C interop is fairly straightforward, and Objective C is a superset of C so that is a total non-issue.
The ability to easily integrate the wealth of C libraries directly into your high-level code (as opposed to, say, the verbosity of implementing a JNI) is one of the strengths of Swift.
What's a C++14 shader? Metal uses MSL last time I checked...
> manually compilation of shaders
The toolchain for this in Vulkan is pretty solid. It's actually nice to be able to write shaders in a high-level language, and then compile them down to SPIR-V which is more likely to be interpreted consistently across drivers than a high-level language.
Yes but there's nothing surprising about the Walled Garden Company promoting their own snowflake version of Vulkan and insisting everyone who wants to run software must do things their way. This is the same company who has totally locked down the tooling to create and publish iOS apps to only be possible on their hardware.
To be fair, Metal is more than a "snowflake version of Vulkan". For one thing, it was in production before vulkan, largely to address the issue of OpenGL's overhead on mobile devices, and basically it achieves that goal. Also there are certain things which are exposed in Metal which are not in Vulkan, for instance more control over the tile memory which mobile GPUs use. So it's not as if there is no reason for Metal to exist (of course I would be happier if Apple contributed to Khronos to get those features in Vulkan instead).
But the walled garden approach seems counterproductive here. In the days of Microsoft's dominance Apple made an effort to make windows formats usable on Apple because that meant it would be easier for consumers to switch to Apple without worrying about losing all their stuff from Windows. With regard to applications in which graphics API's are relevant (i.e. games) Apple still has a minuscule market-share, and it seems like they would be well served by adopting the dominant technology. Lock-in only works if you're already winning.
Some devs are so obsessed complaining about Metal that most aren't aware that UWP and Windows Store are DirectX only.
An advantage of all proprietary 3D APIs is the amount of out-of-box infrastructure code, debugging tools and having progressed beyond C, while Khronos APIs are still mostly C, and requiring creating mini-engine from scratch after fishing for libs.
I don't really see the issue with C APIs. IMO C is a fantastic integration point for a library which wants to have the widest reach possible. Interoperability with C is a solved problem in a wide variety of languages, so C APIs tend to be easy to integrate. Also since C is a fairly thin abstraction on top of what a computer actually does, good C APIs tend not to be opinionated about how they should be integrated.
I would consider working with C APIs to be a basic programming skill.
> With regard to applications in which graphics API's are relevant (i.e. games) Apple still has a minuscule market-share, and it seems like they would be well served by adopting the dominant technology. Lock-in only works if you're already winning.
Except Metal is the dominant API on almost all Apple platforms. Metal supported-iOS devices are at 700 million (last year's WWDC stat) and majority of games are using Metal on iOS. You can't ignore that market, iOS games are very profitable.
Well as you say, Metal is really for iOS. And I think the evidence points to Apple caring much more about iOS than the Mac. So it makes sense from that perspective.
That's the second endorsement of an IOGEAR DisplayPort solution I've seen so far. The full product line is here: https://www.iogear.com/solutions/kvm
$480 to solve the dual head 4K DisplayPort problem, and it works, apparently.
Now, is that a reasonable price? I have to say I think so. This is not a trivial problem and this equipment isn't being manufactured by a dozen companies and flying off Best Buy shelves. Given the low demand and difficult requirements I think the price is reasonable. If your use case involves smoothly switching between 2-4 high resolution dual head systems $480-$680 probably amounts to something in the range of 5-20% of the cost of the entire system.
I don't buy the argument that this cost makes such a KVM pointless because one can simply buy more display(s) and input devices instead: that takes a lot of space and results in a lot of underutilized hardware.
The two most interesting companies in crypto for me right now are KeyBase, and Wire.
I kind of wish there was some way for them to interact with each other, because it feels like they each have a piece of some bigger puzzle.
part of the point of jekyll to me is being in control of all the markup on the page, which is why the idea of using a theme goes against how I would use it.
I would but honestly, there are far more important things that need their effort. t61 requires a bit of work to actually get the music. youtube-dl supports it, but only one at a time.
I ran a large online community with tens of thousands of users that existed for nearly 19 years. When it came time to close it down, I left a notice on the site for several months before i made it read only...
then the helpful guys at archive team[1] helped me create a complete archive of the site on archive.org with their irc bot.
once that was complete, i replaced the site with a notice and linked to the archives from there.
As an aside, one of the old domains that we used for a while lapsed at some point, and some spammer put up a copy of the pages from the internet archives with ads injected into the content. That eventually went to an SEO landing page a few months later.
For those that don't know, Archive Team and Internet Archive are two different groups (though with an overlapping membership).
Internet Archive are a non-profit org that are legally held to high standards, as they should be. They're a very stable place to have data archived. That comes with a few limitations, like not making information available if there's any (even accidental) indication that the upstream site want it kept private - see the comments about robots.txt in tfa.
Archive Team, on the other hand, are a fairly fun and radical group that are far more loosely organised, who will archive what they can when it's needed, and horde it. Fuck your robots.txt![1]
If you can get involved in either organisation, it's highly recommended. They both have interesting challenges and solve them with neat tools.
