MAD even had an impact on Donald Knuth; his first publication was in fact "The potrzebie system of weights and measures" in 1957, defining the basic unit, the potrzebie, to be exactly the thickness of MAD 26 (2.263348517438173216473 mm) published in MAD 33. [1] [2]
Yes, it would be great, but it is most likely not happening anytime soon. As previously discussed on the WebGL mailinglist, Vulkan is strictly (and rightfully, wrt performance) working against all the security considerations that went into WebGL by design. A "WebVulkan" would thus not be much of a benefit, or even usable, if it's severly crippeled in it's features.
Even though Vulkan for would be of little gain for the web due to all the security considerations required, a WebGL backend should still be able to benefit from being built on Vulkan instead.
Due to the refinement of the pipeline and memory access, etc. provided by Vulkan, there's a lot of room for optimization.
___
Though on the other hand, even with additional overhead on a Vulkan web API, the improved state management and access to command buffers may still allow for smarter rendering with negligible overhead via JS
I completely agree and one could theoretically do away with things like ANGLE! Though, I also suspect that the implementor's overhead is rather large in contrast to the current way WebGL is implemented in Chrome and FF, which is currently a relatively 'thin' layer on top of OpenGL.
On the other hand the nature of implementation in Chrome, i.e. does seem to lend itself somewhat to a command buffer approach as in Vulkan.
I am somehow reminded of a snippet of a Jesse Schell talk back in 2010 [1] when he predicted convergence of technology in the pocket ... I, too, suspect devices are going to converge towards a device that can be held with both hands, has maximum screen real-estate and still fits in a pocket. One hand usage seems less important as the hold-to-ear phone aspect is slowly phased out as a valid use-case for these devices.
Indeed compliance is an issue with IRC, but you don't need to write an IRCd to log all messages and you don't even need to configure IRC services: you could just use InspIRCd [1] (which, by the way, is a superb and extensible IRCd) and an extension such as [2] to achieve what you are looking for.
I'll have to give it some investigation. I'm pretty confident in the ability of end users to figure out a basic IRC client, but logging made it a non-starter for our use cases - the chatlog module you linked is rather basic, but looking at the source it should be easy to extend for our usage.
Great idea! But wouldn't it be best to restrain the output of htop to a few interesting processes that are running without root privileges. It seems to me that it could be possible to bubble up processes that can leak information, especially at startup and when you put the server under load externally...
