Subject: Editorial | February 16, 2017 - 06:36 PM | AlexL
Tagged: Zen, Z170, webkit, webgpu, podcast, Optane, nvidia, Intel, icx, evga, ECS, crucial, Blender, anidees, amd
PC Perspective Podcast #437 - 02/16/17
Join us for EVGA iCX, Zen Architechure, Intel Optane, new NVIDIA and AMD driver releases, and more!
The URL for the podcast is: http://pcper.com/podcast - Share with your friends!
- iTunes - Subscribe to the podcast directly through the iTunes Store (audio only)
- Google Play - Subscribe to our audio podcast directly through Google Play!
- RSS - Subscribe through your regular RSS reader (audio only)
- MP3 - Direct download link to the MP3 file
Hosts: Allyn Malventano, Ken Addison, Josh Walrath, Jermey Hellstrom
Program length: 1:32:21
Podcast topics of discussion:
Week in Review:
News items of interest:
Hardware/Software Picks of the Week
Subject: General Tech | February 9, 2017 - 03:46 AM | Scott Michaud
Tagged: webkit, webgpu, metal, vulkan, webgl
Apple’s WebKit team has just announced their proposal for WebGPU, which competes with WebGL to provide graphics and GPU compute to websites. Being from Apple, it is based on the Metal API, so it has a lot of potential, especially as a Web graphics API.
Okay, so I have mixed feelings about this announcement.
First, and most concerning, is that Apple has attempted to legally block open standards in the past. For instance, when The Khronos Group created WebCL based on OpenCL, which Apple owns the trademark and several patents to, Apple shut the door on extending their licensing agreement to the new standard. If the W3C considers Apple’s proposal, they should be really careful about what legal control they allow Apple to retain.
From a functionality standpoint, this is very interesting, though. With the aforementioned death of WebCL, as well as the sluggish progress of WebGL Compute Shaders, there’s a lot of room to use one (or more) GPUs in a system for high-end compute tasks. Even if you are not interested in gaming on a web browser, although many people are, especially if you count the market that Adobe Flash dominated for the last ten years, you might want to GPU-accelerate photo and video tasks. Having an API that allows for this would be very helpful going forward, although, as stated, others are working on it, like The Khronos Group with WebGL compute shaders. On the other-other hand, an API that allows explicit multi-GPU would be even more interesting.
Further, it sounds like they’re even intending to ingest byte-code, like what DirectX 12 and Vulkan are doing with DXIL and SPIR-V, respectively, but it currently accepts shader code as a string and compiles it in the driver. This is interesting from a security standpoint, because it obfuscates what GPU-executed code consists of, but that’s up to the graphics and browser vendors to figure out... for now.
So when will we see it? No idea! There’s an experimental WebKit patch, which requires the Metal API, and an API proposal... a couple blog posts... a tweet or two... and that’s about it.
So what do you think? Does the API sound interesting? Does Apple’s involvement scare you? Or does getting scared about Apple’s involvement annoy you? Comment away! : D
Subject: General Tech, Mobile | April 6, 2013 - 09:47 PM | Scott Michaud
Tagged: webkit, Blink, Android, Google Chrome, ChromeOS
There once was a web browser named Konqueror which was quite common in the Linux community. At its core was the KHTML rendering engine, a nice standards-compliant layout package; KHTML was so nice that Apple decided to create WebKit based on it. Since then, WebKit has been the basis of Google Chrome and other applications such as Steam as of a few years ago.
And even though the project maybe never be done, Google stuck a fork in it.
Blink is a new layout engine, based on WebKit, soon to be implemented in Google Chrome. By soon, I mean practically the next release. It stands to reason, too: a forked project by definition starts out looking nearly identical because they both start from the same point. The two projects will be able to evolve in different directions as each begin to differ in needs and desires.
So what does it mean? Firstly, web developers do not need to worry about a new vendor-prefix until at least Google starts to worry about one. According to their above Q&A, they currently seem more interested in reducing prefix support rather than adding new ones. Personally, I expect that at some point they will likely need to add some as standards evolve.
In terms of the future: I feel that multiple rendering engines will only be better for the future of the web. Sure, it can be difficult for web developers to test their products across a variety of devices but that is a drop in the bucket compared to the misery caused when a dominant player gets complacent. A noncompeting player will stop innovating and maybe pull away from open standards.
Then again this pretty much always happens: no-one is satisfied with monopolies. Thankfully the WebKit license made it easy for dissatisfied parties to take action. In turn, WebKit can benefit from many of these developments at their leisure, particularly before their products look too dissimilar.
Subject: Editorial, General Tech | February 2, 2013 - 11:23 PM | Scott Michaud
Tagged: webkit, w3c, microsoft, internet explorer, html5
Microsoft has been doing their penance for the sins against web developers of the two decades past. The company does not want developers to target specific browsers and opt to include W3C implementations of features if they are available.
Microsoft traditionally fought web standards, forcing developers to implement ActiveX and filters to access advanced features such as opacity. Web developers would program their websites multiple times to account for the... intricacies... of Internet Explorer when compared to virtually every other browser.
Now Google and Apple, rightfully or otherwise (respectively, trollolol), are heavily gaining in popularity. This increase in popularity leads to websites implementing features exclusively for Webkit-based browsers. Internet Explorer is not the browser which gets targeted for advanced effect. If there is Internet Explorer-specific code in sites it is usually workarounds for earlier versions of the browser and only muck up Microsoft's recent standards-compliance by feeding it non-standard junk.
It has been an uphill battle for Microsoft to push users to upgrade their browsers and web developers to upgrade their sites. “modern.IE” is a service which checks for typical incompatibilities and allows for developers to test their site across multiple versions of IE.
Even still, several web technologies are absent in Internet Explorer as they have not been adopted by the W3C. WebGL and WebCL seek to make the web browser into high-performance platform for applications. Microsoft has been vocal about not supporting these Khronos-backed technologies on the grounds of security. Instead of building out web browsers as a cross-platform application platform Microsoft is pushing hard to not get their app marketplace ignored.
I am not sure what Microsoft should fear most: that their app marketplace will be smothered by their competitors, or whether they only manage to win the battle after the war changes theaters. You know what they say, history repeats itself.
Subject: General Tech | August 6, 2012 - 09:55 AM | Tim Verry
Tagged: windows, webkit, security, safari for windows, safari, browser, apple
The Apple-developed Safari is one of the least popular webkit-based browsers on Windows. Even so, it still commands 5% marketshare (across all platforms), and that is a problem. You see, many sites are reporting that Apple has dropped support for Safari on Windows. Windows users will not get the update to Safari 6–the new version available to Mac OS X 10.6 and 10.7 Mountain Lion users. As well, it seems that Apple has removed just about every reference to ever having a Windows version of any Safari browser from its website.
Image Credit: MacLife
The issue is that the final version that Windows users are stuck with–version 5.1.7–has a number of documented security vulnerabilities that are never going to get patched by Apple. According to Maximum PC, there are at least 121 known security holes listed in Apple’s own documentation. And as time goes by, it is extremely likely that the number of unpatched security holes will increase. Running an outdated browser is not good security practice, and running a browser that is EOL and has known vulnerabilities is just asking for trouble.
While the number of PC Perspective readers running Safari for Windows is likely extremely small, I would advise that you be on the lookout next time you are doing tech support for your friends and relatives, and if they managed to get roped into using Safari thanks to Apple’s Itunes software updater convince them to move to a (dare I say better) more secure browser like Google’s Chrome, Opera, or Firefox. At least those are still getting updates, and some are even automatically done in the background.
Have you ever used Apple’s Safari for Windows browser? What would you recommend as the best alternative? Let us know in the comments below.