f_

I don't think this is true; I am running Microsoft 365 and use AWS Route 53 and manually set up DNS records to work with Microsoft 365 just fine.

For me it's clearly Vim. Changed my life for the better.

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]

[1] http://cs.nyu.edu/shasha/outofmind/knuth.html [2] https://blog.codinghorror.com/the-enduring-art-of-computer-p...

Hehe! Thanks for the clarification -- I wondered if everyone was going bananas over at your company! This explains it (:

Very interesting indeed; but somehow I was even more baffled at the package names they seem to be using:

  com.netflix.vulturemonkey.cow.iguana.MacawSquirrel

  com.netflix.ape.serpent.vulture.ApeVultureMantis

  com.netflix.iguanas.monkey.insect.IguanaRabbit

Any idea what's up with that?

I've read this a long time ago and it seems to be still mostly true! A more recent statement of Knuth about email is here: https://www.youtube.com/watch?v=QS8qwMna8_o

The CEPL [0] project could be of interest to you! Pretty great approach to OpenGL from CL.

[0] https://github.com/cbaggers/cepl

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.

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.

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.

[1] http://www.realtimetranscription.com/showcase/DICE2010/Jesse...

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.

[1] https://www.inspircd.org/ [2] https://github.com/joshenders/inspircd-m_chatlog

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...

There was a recent HN topic here on the redox-os[0] which is written in Rust (and heavy WIP). It did actually use a lot of unsafe, though.

[0] https://github.com/redox-os/redox

As Knuth himself said, literate programming facilitates the task of thinking about a problem without having to use a formal language to construct such understanding bottom-up. Therefore literate programming can, for example, produce much less stack depth in a program while making it easy to understand and maintain. This is quite an interesting aspect with regards to performance of the resulting code, that is often overlooked. He also claims that if TeX had been written without it it would not have a depth of 4-5 subroutines on the call stack, but around 50-100 [1]. He also states that he would not have been able to produce MMIX [2] without literate programming because he would not have been able to reason about it's design bottom up [1].

So, a lot of complexity is added to a program just so that it can be understood and maintained in a formal language; but he also states that many modern comment styles go a long way towards literate programming.

Having worked on large codebases I concur that using literate programming to construct these seems far-fetched and too academic, yet I am enticed by the idea of optimizing code by literate programming since I have seen far too many abstractions for the purpose of maintaining easy to read code.

[1] http://www.codersatwork.com/ [2] http://mmix.cs.hm.edu/

Nice work and thanks for sharing. I'd like to add this blog post [1] I read a while ago that explains a bit how to write a disassembler and emulator for Chip-8. The source is not as clean as yours and written in C but it's still worthwhile to check out.

[1] http://emulator101.com/chip-8-disassembler/

Does anyone know whether the JVM/JIT generates SIMD instructions for code like this? Looks like a pretty obvious target to me.

This is a pretty neat concept; I've come across this some years back in bisqwit's video https://www.youtube.com/watch?v=lxZyxxHOw3Y - he call's it "enfragmentation".