Browsed by
Month: February 2017

ArchLinux on MBP Installation Guide [大部分内容适合普通ArchLinux安装] 上

ArchLinux on MBP Installation Guide [大部分内容适合普通ArchLinux安装] 上

TL;DR 这两天OS X的虚拟机挂了,两个月的工作成果都丢了,因为本人是重度Archlinux依赖用户既然虚拟机这么难用(不能用全部内存&有快照损坏的风险)因而,唯一的选择就是在MBP上装Archlinux了。同时因为这是第一次用UEFI的模式Dual boot Archlinux + OS X,并且是第一次使用KDE而不是一直用的Gnome,因而踩了很多坑,所以本文会比较长( 本文介绍的是在MBP上Dualboot OS X + ArchLinux 使用KDE并配置好所需的必备软件的整个过程 ArchLinux 优点 如果连这个都不知道的话那么说明可能温豆师/污班图还是比较适合你((其实是很麻烦不想写因为已经写烂大街了 那么我们就开始吧OwO 材料准备 一个容量足够装下ArchISO的U盘 一台Macbook 畅通的网络 一些干粮(不然熬久了会饿的) rEFInd 不确定是否要禁用Apple的 Configuring System Integrity Protection 如果在操作引导过程中遇到问题,那么就设置一下这个 足够大的空间(用OS X 自带的 Disk Util 将要用来装Arch的空间划分出来,不用管文件系统,反正一会儿也得删) 引导安装 EFI 介绍 EFI boot是比 BIOS Boot 要先进的 boot 方式,古老的 BIOS 需要让CPU先进入16bit的实模式,仅仅能执行有限的一些 BIOS 提供的中断,并且 BIOS因为是直接用CPU的汇编编写的,对硬件平台有非常高的依赖,包括在BIOS下运行的驱动,尤其网络驱动,还要独立的给每一个架构的CPU编写一套独立的驱动,维护难度和开发难度都比较高,而 EFI 加载的驱动是以 EFI 字节编码 ,独立于CPU架构,因而更优,且BIOS无法支持大于 2TiB 的硬盘,因而对目前的很多机器这都是致命的瓶颈 (参考资料), 因而目前的个人PC开始采用 UEFI (EFI的一个更新版本)进行系统的引导。 引导过程以及ESP EFI 的引导不同与 BIOS,不需要将 Bootable program 放在 first sector ,而是将引导程序放在 ESP 中 ESP (EFI System Partition) 存放了EFI引导的必备程序,路径格式需要符合此规范<EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI (此行摘自wikipedia) 例如/efi/BOOT/BOOT (具体识别哪个路径,以及能否识别不同的路径跟固件的实现有关,具体讨论如下…

Read More Read More

Eudyptula Challenge 1 — 8 总结

Eudyptula Challenge 1 — 8 总结

TL;DR (PS: 昨天竟然在一个非计算机领域的朋友口中听到TLNR好神奇) 从开始做eudyptula-challenge已经有一个多月了,也从原来的连第一关都会卡关好久到现在第八关只用了不到四十分钟的时间就写好了(虽然第八关的coding要求很简单,主要是要练习git send-mail的使用方法)随着Challenge的进行,之前关卡学到的一些东西难免会遗忘,因此在继续进行之前,现将前面学到的知识进行总结。注意: 本文不是Eudyptula Challenge的攻略,Eudyptula Challenge明确禁止了对答案代码的公布和分享,个人也赞同这种做法,毕竟是Challenge,需要你自己研究,而不是直接上网就能搜到答案(尽管现在的确能搜到答案了,比如某章鱼猫(( Intro What is Eudyptula Challenge? 这里就引用官网的介绍了 The Eudyptula Challenge is a series of programming exercises for the Linux kernel, that start from a very basic “Hello world” kernel module, moving on up in complexity to getting patches accepted into the main Linux kernel source tree. How does it work? 官网上也给了相应的介绍,不过窝认为从一个例子来介绍更为形象: Eudyptula-Challenge的评判系统是由”A set of convoluted shell scripts that are slow to anger and impossible to debug.”(摘自官网)来进行的,也就是全部自动评测(不过有的时候它的只能程度让我猜想后面有人在操作*****(大雾 以一个Task为例, 当你注册成功Eudyptula Challenge之后,会收到一封说明邮件以及你的第一个任务,之后你所有的任务提交都将通过在第一个任务里给你分配的ID以plain-text mail的形式进行。 当你收到一个Task的时候,根据相应的知识完成任务要求的代码之后,你需要通过纯文本邮件客户端(如mutt)将proof运行结果的输出作为正文,将写好的代码作为附件(这里不能用gmail的plain-text模式,因为它会把邮件附件转为base64格式)通过客户端发送给[email protected],之后你会收到一封通知邮件,表示系统已经成功收到你的提交(有可能收不到,因为脚本也许会卡住,这时候你如果等了一天还没收到,那你可以再次发送一封,不要频繁重发,小企鹅会生气的(不要问我怎么知道的Orz)) 通知邮件的格式是这样的 blabla,…

Read More Read More

Gmail + Mutt 报错 no authenticators found 解决办法

Gmail + Mutt 报错 no authenticators found 解决办法

初步测试是配置文件错误导致的,这里要注意几个配置不要填错 下面是一个可用的配置 set imap_user = ‘[email protected]’ set imap_pass = ‘************’ set folder = ‘imaps://imap.gmail.com/’ set spoolfile = +INBOX set record = “+[Gmail]/Sent Mail” set postponed = “+[Gmail]/Drafts” set smtp_url = ‘smtps://[email protected]’ set smtp_pass = ‘***************’ 注意: smtp_url 要填写 smtps://[email protected] 而不是下面的其中一种 smtps://[email protected]@smtp.gmail.com:465 smtps://[email protected]:587 。。。 填写正确之后, 可以使用mutt进行邮件的发送