@jukka Web 前端的核心部分，还真跟 OpenGL 关系不大。
OpenGL 是一个 GPU 3D 绘图的 API ，而前端渲染主要涉及的是 2D 矢量绘图，如果你只是搞游戏的话，对矢量绘图可能不是很了解。
简单来说， GPU 不适合 2D 矢量绘图。

游戏（尤其是追求画面效果的 3D 单机游戏）的 rendering 部分的最大目标之一是用最少的硬件资源得到最好的即时渲染效果，这个“好”往往是和“真实”相对应的，聚焦于灯光、贴图等方面，利用的图元是点、面等。而矢量图中，最重要的图元是 Path （有点像 PS 里面钢笔画出来的那玩意， SVG 里面也有涉及），对于填充、线型、曲率等细节的正确性要求较高，同时还存在一个文字排版的问题（这个倒是和游戏沾点边，因为 3D 里面到处都是的贴图无法直接解决游戏 UI 文字渲染的问题）。

剩下的事情很简单，假如要用 GPU 渲染一个无填充矢量圆环路径，用单个四边面表示的话，那是对像素填充率的浪费，如果利用 3D 建模中的手段，大量面片拟合的话，且不论效果好不好，效率又成了问题。

错误信息已经告诉你是 exec format 不对了，不过这只是最表层的问题，其他的详细 https://en.wikipedia.org/wiki/Application_binary_interface

碰到这种情况如果我手头没 Linux 的话也可以放 VPS 上面试试。

中文都说不顺口的默默拿小本记下…

@joshz 能否八一下 恶魔的奶爸被扒皮 是什么事情？

HN 和 V2 貌似不是一个等级的
StackExchange 的各个分站， Quora ，也是形式有些不一样
Reddit 有种西方的百度贴吧的感觉
各种 mailing list, Google Groups
还有各种专门的论坛，比如 ArchLinux ， React

再偏一点的就是 Twitter 和各种零碎博客
想找一个和 V2 差不多的还真有点难

滋瓷 TypeScript 的库不多啊。

不过为啥那个链接 404 了...

我把 ww, www, wwww 几个全都 301 到了 @ 下面...

不过我跟楼主一样，在买域名之前也不懂这套理论，哪怕计网的课程很早就讲了 DNS 。

@hongfeiyu 过俩小时好像就差不多了
反正常用的几家应该都行，大陆或者一些 local 的反应可能慢一点。

@Cassandra 中国教育确实重视英文，但是鉴于整体面向考试的定位，其实并不全面，就像 @ferrum 同学说的，连标点后面要加空格都不会注意。

但是如果是本贴这种情况的话，我觉得锅不能推给教育。

刚看到标题，学完？编译原理能学完？给跪了


@initialdp 貌似编译原理一开始习惯性的用 C ， Pascal 之类的做背景，到后面要是点类型系统之类的技能的话就奇葩辈出了..

这东西我已经用了半个月了吧，简单介绍一下使用体验。

我其实不大喜欢 Markdown 原生语言不能在内部定义 class 和 style 的，所以一直在寻找替代方案。

Madoko 这个东西相比与核心 Markdown 在各个方面都有很大的不同：

MD 从自身体量和定位上看都是个很简单的东西。 MD 的 reference 就半屏幕的篇幅， Madoko 的自己去看 ( http://research.microsoft.com/en-us/um/people/daan/madoko/doc/reference.html)。相比于 MD 的物尽其用，字字珠玑（貌似用词不是很准）， Madoko 有一些东西实际上是我们几乎不会用到的（那个 reference 我只看了一半就放弃了），或者说按我的理解，和 C++ 或者 JS 之类的一样，用一个“子集”就好了。

这个主要是因为 Madoko 的定位是*写论文*，虽然作为没有相关经验的我对其是否堪当此任有点怀疑，但是我拿它弄个期末作业是没什么问题的。所以我认为 Madoko 和楼上诸位提到的各种“编辑器”不是一个量级的，编辑器一般是卖界面送语言， Madoko 是一套（目前只有一个 Apache 协议的 Koka 实现的）的语言附带一个编辑器。其语言本身和 MD 就不是一个量级的（和 GFM 不完全兼容）。

讽刺的是，虽然 Madoko 貌似从语法上实现了更高的可扩展性，但是我并不觉得这个软件本身是一个优秀的实践。其中有一个原因可能是 Madoko 的另外一个 intention ，就是他们的 Koka 编程语言的一次 show off 。这套轮子我个人目前兴趣不是很大，但是大概是他们研究工作的一部分。 Madoko 的在线编辑器*能用*，你用 npm 装到本地也能用，但是如果想把它当一个库，在 Node 里面写脚本转译就没那么容易了。

这方面作者还是做了一定工作的，也就是说直接 require('madoko') 的话，确实是可以成功的，然而它返回的接口和命令行直接调用 madoko 工具并不完全一样。直接 require 然后调函数的话会死的很惨——正常的 Madoko 输出依赖于一个类似于标准库一样的 prelude 文件，此外还有文本中的 include 之类的一系列依赖 fs 的问题，这个 Madoko 的核心是不会处理的。

另外，它默认使用了一个叫做 Monarch 的库做代码语法高亮（应该也是他们自家东西）。我 Google 了半天几乎找不到任何资料。其实如果给一个黑箱一样的东西，外面直接调（类似 highlight.js ）也是可以的。但是这它要求你对文章中使用的每一个语言，单独注册语法定义数据，这个定义是分语言储存在 JSON 文件里面的， Madoko 的作者十分简单粗暴的把 Monarch 做了个 minify 放在 lib 里面（还没给 License ），定义文件（很偏心的给了一个 Koka 的，但是没有 Bash 的）和 prelude 一块扔在包里面。在 CLI 的入口里面正则匹配内容，一个个注册——要是想在脚本里面用语法高亮的话，这部分代码你得重写。

实际上楼上也提到作者和 VS 一些相关项目的关系，我在网上找到的有关 Monarch 的唯一一个有用信息就是这东西*貌似*也被用在了 VSCode 里面，代码在 GitHub 上直接能找到，但是好像接口不是完全相同，并且是 TypeScript 写的。顺带，我觉得 Madoko 如果也是用 TypeScript 写，大概会更切合微软近年的工程实践，奈何这东西是实验室里面出来的...

不发牢骚了。这东西一个很激进的地方在于，不同于 MD 直接转换成 HTML ， Madoko 更偏向于 LaTeX 。我认为这意味着相比于 MD 和其他的 MD 扩展，其功能更完善。比如： Madoko 在导出 PDF 时，是*直接调用 LaTeX *输出的，也就是说你可以通过 LaTeX 语句*准确地控制输出页面的样式*。另外，各类 MD 扩展对数学公式的资词，我见过的一般都是依赖于 MathJax ，这东西缺点在于没有 LaTeX 那么灵活，并且有些还要求在线环境。 Madoko 基本没有这样的顾虑，就算是输出 HTML ，他也会把其中的公式部分提取出来单独用 LaTeX 渲染，然后转成图片贴进去。这些操作让整个转换过程显得不那么轻量。

Madoko 内部其实有两个输出模块，一个是 HTML ，一个是 TeX ，你可以同时产生两种格式的输出。当然我在网站上面用的话，就让他直接产生 MathJax ，然后打了个专门针对 LaTeX 输入的 MathJax 单文件包（我很讨厌 MathJax 的异步加载），然后客户端渲染。另外， Madoko 自身没有提供对中文的直接资词，所幸 HTML 根本没这个问题， PDF 的话加几个 LaTeX 的 Metadata ，效果和直接写 TeX 文档一样（另一种标记语言， asciidoc 就只有 HTML 能看了...）。在线编辑器上面比较喜感，中文段落全部语法错误... 并且，除了他自己的在线编辑器之外，目前没看到任何一个第三方的 Web/Native/Hybrid 编辑器对 Madoko 的语法提供资词。包括微软前面那帮人做的，我经常使用的 VSCode ，不过 VSCode 开放插件了，憋出一个来我感觉体验会比在线的要好。

@Arthur2e5 Madoko 有两套 prelude ，一套是给 HTML 的（就一点 CSS ，貌似还有 JS ），还有一套是给 TeX 的，我觉得要真想修没有流程图的“硬伤”的话，也可以学着这么干 233

@xrxsh 用了三年的低端手机的跟你说：浏览器压根不敢开，倒是 Google Play 上面下的小应用玩的挺 6

音质感觉都没什么， ipc 我现在一周也就听那么一两次，主要是没什么正版音乐，盗版也不想整理

啊不过感觉在下架之前（ 2013 ）买到的好幸运

针对好奇楼主为什么会发现的

我有一个猜想，看原文：

> 躺着或者倒过来才能开机

如果台式机打不开了，放倒机箱看看怎么回事应该很正常吧

至于为什么会想到上下颠倒过来的... 我也很纳闷

诶说来我做的外包基本属于双方都是毛都不懂的那种

结果是两边都坑...