司机产品的四个关键问题

作者:刘言飞语©-虎嗅网, huxiu.com

本文来自微信公众号:刘言飞语(ID:liufeinotes),头图来自:东方IC。

很久之前我曾经写过一条消息:

时隔许久,是时候整理出来跟大家分享了。

在这之前,要先补充几点:

1.高阶产品经理和产品负责人,与初阶产品经理的主要区别,在于前者对业务的认知足够深入,可以做出更高维度的决策。如今普适型的产品经理,或称体验型的产品经理,早已过气,垂直领域深耕才有前途。我曾经在知乎上写过一篇赞同数居然有 2.8k 的回答“高级产品经理和普通产品经理的区别”,如今看来实在过于粗浅。

2.对行业的认知是难以在行业外猜想出来的,哪怕蒙对了,也不值得庆贺。要深耕一个行业,势必要进入这个行业,离用户足够近。我在到滴滴之前,在出行行业里也是小白一个,需要几个月甚至几年的沉淀,才能对业务和用户有较成熟的认知。

3.离用户足够近,离业务足够近,需要的是长期的体验和调研。这种调研不是像尼尔森或者盖洛普那样的专业调研,而是亲身体会。我在滴滴接了66单快车,参加过许多活动,日常跟司机有频繁的交流沟通,但觉得还是有不足。

4.除了体验和调研,还要有机会去验证更新。没有得到验证的认知,其实是廉价的、不确定的。在司机方向参与的许多次迭代,正是验证认知的机会。当然,由于众所周知的事件,后来可验证的空间并不大了,很可惜我的认知里有不少也是“纸上谈兵”,未必都是板上钉钉的真相。

5.以下的思考里,没有个人价值观的表述,均是描述客观事实。有一些与普世价值观不符或认知不同的地方,很正常。这是用户和产品实际情况“实然”的思考,不是评价生态正确与否的“应然”的思考。

6.以下的思考,只代表个人观点,不代表任何组织或他人。文中的信息除了个人思考总结,均为公开信息。

7.以下的思考,比较干,可能大部分新人读者会觉得涩,或搞不懂有什么价值,没关系,过段时间有类似的困惑再回来读,会更有体会。同时,对许多关于 to 小B 用户(司机、商家、骑手、民宿老板等)的产品,应当有更直接的借鉴意义。

正文开始。

司机产品面临四个关键问题:

第一部分,司机的核心需求是收入和自由度。

收入,是司机最核心的需求,这点人尽皆知。这也是与乘客产品面临问题区别最大的一点:司机会更集中在单一的结果需求上,乘客会聚焦在综合性的需求体验上。

比如,假如整体体验很差,但最终结果看,收入还不错,司机往往选择忍耐(当然并不是体验没有意义,它会影响司机的权衡和折损,却不是核心要素)。反观乘客,则是不只看重到达目的地这一单一结果,也会看重等待时的体验、车上的体验,对网约车的品牌是个综合的认知。

满足司机收入需求面临的一大衍生问题,当然就是媒体和舆论中最常提到的抽成问题。网约车司机的收入构成里,从总量看,奖励补贴大约占到快一半的量,这也就意味着,平均 20% 的抽成,其中有 10% 是通过奖励补贴形式返还给司机。从司机整体收入来看,抽成其实并没有描述的那么严重。

那么有几个问题来了。

第一个问题,可以减少奖励补贴,降低整体抽成吗?

答案是,可以,但很难。奖励补贴的核心目的是完成调度匹配,即用时空奖励(限定时间的或限定空间围栏的奖励)来让整体供需尽可能平衡。

那非要去掉奖励,让司机自己调配自己不行吗?这样的难度非常大,每个人做自己决策时不会考虑到连锁的影响,以及长期的影响。整体供需匹配的平衡,有利于司机接到更多单,反过来也有利于乘客的订单容易被接到,对双方都是更有益的结果。

供需平衡是另一个非常大的课题,这里就不展开讨论了。我们只需得到这个结论:供需平衡目前最有效的方法是将收入以有条件发放的方式给司机。

网约车领域也都在积极尝试优化调度系统,不过不出奖励补贴要让司机听从调度,又是另一个艰难的课题了,与“司机遭遇问题是必然事件”有关,我们下文再提。

要真正解决这个问题,恐怕真的要无人驾驶时代到来。

第二个问题,这么多司机抱怨抽成,就不能把“奖励也有很多”的概念传递给他们吗?

答案是,可以,但没啥意义。有一位高阶产品朋友就这么建议过我,她平时跟司机沟通觉得司机对抽成的怨气太大,理应把整体收入比如月收入、周收入都呈现给他看,这样能缓和司机的负面情绪。

实际上这个分析界面很早就做过了,部分优化还是我自己操刀的。但我们对这个功能几乎没有太高的预期,原因很简单:绝大多数司机早就知道了,并不需要你告诉他们。

试想一下,你把网约车当作自己的职业,会不在意自己的月收入、周收入吗?哪怕没有这个分析,每个司机都对自己赚了多少钱,无比清楚。产品上提供功能,无非就是优化体验,以及打消司机之外的人群(乘客、媒体、大V)对网约车公司的负面评价。毕竟后者人群不了解司机的总收入,只看到每一单的抽成。

那么司机抱怨抽成,到底因为什么?其实是因为他们始终有“订单收入是我应得的收入,而奖励是我额外白赚的”这种心智。在这种心智下,他们在看待月收入时,会觉得满意,觉得是运气好白赚了不少奖励;看待每单抽成时,却觉得生气:平台凭什么抽这么多钱?

他们不会把抽成和奖励关联起来,这种心智是核心缘由,非常难解。

第三个问题,司机如此抱怨抽成,继续这样下去,司机都会流失的吧?

答案是,短期不太可能,长期有风险。司机对平台的抱怨,当然会成为选择继续做网约车的心理成本,不过司机要流失的话,一定要面临另一个问题:不做网约车能去哪。这也是做用户分析很重要的认知:你的用户,他们能从其它何处满足需求?

对网约车司机群体来说,满足的需求是一份相对稳定的收入,竞品是什么?就司机群体而言,是其他的蓝领工作。

之前我们做过调研,很让人惊讶的是,在所有蓝领工作里,网约车司机的收入哪怕在补贴大战彻底结束后,也依然是排在非常前面的。而其它排在前面的工作,往往需要更多的技能。

这也是为什么许多司机持续抱怨,却仍然不会离开平台。实际上他们的需求已经得到了满足,只是各种额外的因素(下文会提到),会导致怨气很重,对平台不满。加上连续工作的疲劳需要发泄,这种压力就转给了乘客,继而引发了社会舆论的谴责。

这种抱怨的问题短期内,由于司机没有流失去处,并不算严重。长期看,要么是有竞品进入(美团来到上海时,不少司机单纯是对滴滴有怨气而流失),要么是心理疲劳成本太高、宁愿选择收入低得多的职业,都会造成巨大的损失,这些司机通常是无法挽回的。

第四个问题,司机对收入的需求是否就只是月收入、周收入这样的绝对值呢?

答案是,并不是。司机对收入的需求包含两点,第一是绝对值,第二,则是“确定性”。

确定性的收入,指的是像我们平时工作一样的状态,上个月 1 万,这个月 1 万,下个月还是 1 万;不确定性的收入,则是上个月 2 万,这个月变成 5000,下个月又变成了 1 万。

由于以下几个因素的影响,导致司机收入的确定性比较差:

这几项的不确定性,让司机的收入始终飘忽不定。平均值是满足需求的,方差往往不尽人意。这与抽成过高的心智感受一样,也让司机的心理成本变高。网约车行业的一些司机聚众闹事事件,大多都是政策变化引起司机成本沉没所致。

因此要做好收入方面的稳定性,需要从司机视角更多整合平台的策略和信息的传递,不仅是从平台调配运力的角度出发做事情,才能让司机收入真正能够稳定下来。

以上是收入。接下来我们讨论自由度。

自由度可能在大家看来比较陌生。自由度的意思是,平台提供接单时可选择的程度,比如时空上的选择权力、或者对乘客的选择权。

最不自由的接单模式,是自营的严格派单,司机作为员工正常上下班,跟打工族没有区别,比如首汽平台的早期模式或者滴滴豪华车的模式。快车是略自由一些的,不过也是派单,只能选择工作时间段,无法选择订单属性。最自由的,当然是顺风车主,可以严格限定订单的时空属性,甚至对乘客也可以有选择。

关于自由度有两个结论。

第一个是我之前有一个假设:自由度与收入需求程度会成反比。即自由度要求越高,对收入的要求就越低。

(收入和自由度成反比)

这个假设的逻辑是,不同自由度对标的竞品(也就是前文提到的从其它何处满足需求)是不同的。

全职司机会把网约车当作职业,目标是养家糊口,对标的自然就是其它蓝领工作,对收入有较高的诉求。

兼职司机则不然,他们是小生意主、清闲的上班族或者自由职业者,他们有一部分完整的时间段(比如每个下午的 4 个小时)可以用来做兼职,对标的是其它的兼职工作。这时可选择的机会其实就少了许多,很难找到像网约车这样门槛低、时间又相对可控的兼职,因此收入诉求会相对弱一些。

顺风车司机需求又变化了,他们是省油费的心理,对标的是“不接乘客空车行驶”,那对收入的诉求又更弱了。

我们无法通过自选的手段或者平台筛选的手段区分全职、兼职和顺风车用户(实则也没必要),而且用户也是会转移角色的(全职司机在每天回家时,实际就变成了顺风车的场景,心里考虑的是可以牺牲收入、能接到顺路的订单就好)基于以上假设,就能用收入+自由度搭建一套合理的生态,场景角色之间可以随时切换,不过要更高的自由度就要牺牲一部分收入,因为更高的自由度=提供给司机个人效率最大化=平台全局效率的潜在损失。

这也能解决从供需匹配看,运力与乘客需求在高峰期平峰期不平衡的问题。在高峰期,可以尝试用更高自由度的需求,拉动兼职和顺风车主来承接需求。基于这个假设的实验在某些城市已经初现成果。

可惜自由度的这套完整生态没有来得及搭建完成和得到充分实验,是我比较大的遗憾。

(模式设置里的功能,也是一种自由度功能)

第二个结论比较简要,是所有司机,哪怕是全职司机,也对自由度有极高的诉求,一类是“想明天不上班就不上班”的这种不被管的职业状态诉求,一类是“回家时需要顺路订单”的场景诉求。

前者是我个人一直反对做太强制的排班与考勤制度的原因,这会导致大量有自由度诉求的司机流失;后者要求产品运营需要考虑类似的顺路场景功能。

以上,就是对司机做用户需求分析得到的几个核心结论。

第二部分,司机使用产品的环境复杂。

环境复杂有两个方面。

第一,司机使用产品的方式与我们使用其它绝大多数产品的场景都不同,他们通常是把手机放在车载支架上使用的。类似的产品使用场景,最接近的恐怕是外卖骑手,不过外卖骑手也一般是停车后双手手持使用的。

司机的这种使用场景,要求产品设计要考虑驾驶场景下的交互和视觉体验,这是最基本的。界面效果上,字体和颜色要醒目,操作按钮要够大、触发区域要够大。另外,大多数需要单向通知的信息,都要配合语音播报。

另外,对平台来说,信息触达的难度增加了不少。因为在驾驶途中,是不能影响正常驾驶、一切让步给导航的,尤其在服务乘客过程中,更严禁有面向司机的播报信息打扰。如果一个司机持续接单的话,有许多信息就会错失,平台无法触达。

(网约车司机常见的使用场景)

第二,司机与乘客是在线下发生交互,这也给场景还原制造了不小的困难。

由于线下通常没有可参考的信息记录,在遭遇多方对事件表述不一致时,几乎没有什么好办法确认真相。我之前有许多听音(在客服中心听投诉和回访录音)经历,听过最夸张的一段,是拼车时车上的三个人(一个司机、两个拼车乘客),对事件的描述居然都不相同。

于是平台判责团队通常只能凭仅有的残缺信息做概率上的判断,无法做出实锤的判断。结果就是,有不少司机会被恶劣撒谎的乘客伤害到,因为就订单频次来说,好司机遇到撒谎乘客投诉的概率,远高于好乘客遇到撒谎司机投诉的概率。

车内录音和视频记录能够解决不少此类困难,不过这又会与司机乘客的隐私权相冲突。关于判责相关的问题,又涉及到太多因素、延伸出来太多问题,这里就不展开讨论了。

第三部分,司机遭遇问题没有解答会过度解读。

这个问题有一个作为先决条件的大背景:司机与平台的信息并不通畅,无论是单向还是双向的。它的造成又有几个原因:


(群里经常充斥着类似的表情吐槽抱怨)

司机与平台的信息不通畅,会让司机觉得不确定性非常强,增加前文提到的对收入稳定性的恐慌。比如一个微信群里流传的假新闻,说新政策有变化,就会很容易当真;或者说平台袒护乘客、提高抽成、无故扣罚等莫须有的问题,更容易被司机口口相传。

加上平台作为互联网产品,的确持续在迭代过程中,产品运营方向看是优化,对司机来说,就是不够确定,甚至有时出尔反尔。今日头条和微信的用户不会觉得一次改版有什么坏处,而且大多数都是好评;网约车产品的改版却会让司机有:好不容易熟悉的工作内容,又要变化,又要重新学习。

这样的用户心智长期积累下,怨言就比较重。这种心智容易演化成行为经济学里的“证实偏见”和“逆火效应”。

前者指人在确信一件事情后,就会主动选择证实的证据而非证伪的;后者指人在确信一件事情后,哪怕是相反的证据,也会成为证实的论据。

再遭遇问题,司机普遍就会更相信偏负面的一种解释。甚至官方出来辟谣,司机也不会相信,反而认为这佐证自己的观点——你不心虚,为什么出来辟谣?

(我根据经验整理的常见反馈和坊间传闻)

这给司机的沟通工作产生了巨大的障碍。平台想要传递的信息且有不少传不到,更不用说传到了的司机还不相信。

有解决方案吗?

各网约车平台在尝试做线下管理。专业的运营通常会更了解情况。不过做起来难度同样很大,做重了,对运营人员的水平要求极高,为了效果可能也要有大量的线下团队,成本收不回来;做轻了,运营人员水平一般或者数量少的话,对司机的帮助就不大,只能充当专业化客服的角色。这块展开讲有许多内容,这里也不展开了。

另外,就是通过稳定司机的体验,让司机对平台更加信任。这是个任重道远的长期工作。

第四部分,司机遭遇问题,哪怕概率再小,也是个必然事件。

我们先算一个数据。

假如司机在一个订单的生命周期中,从接单(不会太久),到接驾(不会太远、不会违停、不会找不到乘客),到途中(导航不出错、与乘客相安无事),到送达(正常结账、收到奖励),我们已经把体验做到了极致,出问题的概率只有 1%,也就是不出问题的概率是 99%,那司机遭遇问题的概率是多少?

作为全职司机,每天20个订单,每个月30天算,600个订单,这个月下来会遭遇问题的概率,很容易算出来,是:99.76%,几乎是必然。更不用说,如今订单出问题的概率比 1% 要高得多。

这本质上也是线下场景复杂的缘故导致。我们用今日头条、微信,通常出问题主要是系统性能的 bug,解决方法也简单:重启能解决 90% 的问题。

而网约车平台作为一个复杂场景下的体验,司机每个订单都要有几十个与平台、与乘客交互的触点,面临的就是极高概率的、甚至可以说是必然会遭遇问题的情景。

因此在讨论司机面临的体验问题时,我们不能定义成 100% 解决,这是没有可能的。我们要定义的,仍然是与收入类似:稳定性足够高,即让大多数司机不会频繁、高密度地遭遇问题。

这里延伸出了第二个问题:既然如此,如何定义司机的体验?

首先,全局订单视角和司机视角看问题解决程度,差别是巨大的。

举个虚构的例子,我们发现司机接乘客上车时,位置有偏差的概率,从全局订单维度看,是 30%,通过一系列的努力,位置有偏差的概率已经降到了 10%,这看似是很可喜的结果。

不过从司机视角重新拆解,会发现遭遇位置偏差问题的司机,由于所处城市或区域的缘故(比如地形复杂),问题非常集中,也就是说,降低的那 20%,只是让大量的每天会遭遇 2 次位置偏差问题的司机,降低到了 1 次,对他们来说,感知不明显;而少量的每天会遭遇 15 次位置偏差问题的司机,可能仍然在遭遇 15 次这个问题。

于是在司机体验这一问题上,我们不能用全局或大盘的问题发生率来定义,而是要用每个司机当天遭遇问题的概率来定义。当天不管遭遇什么问题,只要超过心理接受阈值,就可以认为是“损坏的一天”,每天所有司机里,遭遇“损坏的一天”的人数占比有多少,才是真正体验的晴雨表。

到目前为止,我们对司机产品的四个关键问题已经论述完成。不过,这四个问题仍然是问题集里的基础构成,互相交叉又会衍生出来诸多问题,需要逐一解决。

举个例子,司机接不到单,这是司机体验繁多的问题里,看似只是一小块的问题,拆解出来又会有大量的问题。

司机接不到单,一种可能是附近有单,但自己由于过去行为不端导致服务分(衡量司机服务行为的分数,会影响派单权重)过低,这样场景下要引导司机通过好行为来补回服务分;另一种是附近没有订单,那就要引导司机离开冷区,去有单的热区接单。

就第二个附近没有订单的场景来说,又会衍生出问题:预测该怎么做。订单的产生在全城范围做粗略预测没问题,但要做时空下精准的预测,难度还是很大的。万一有个公司老板今天心情好,提前下班,那周围会突然出现上百个乘客呼叫,这种是完全不可预测的。

既然无法准确预测,也就总会出现失误。这衍生出了新的问题:如何让司机相信?

假设预测热区引导的功能准确率是 95%(已经非常理想化),司机第一次全部都接受,那总有 5% 的司机发现被骗了,这里根本没有订单,付出了不小的空驶成本,再也不相信这个功能。结合前文提到的“遭遇问题都是大概率事件”,这个功能持续运转几个月后,也许每个司机都被失误的预测伤害过,结果就是,几乎没有司机再相信这个功能了,宁愿自己碰运气。

要解决这个心智问题,提升准确率当然是一方面,不过无法根治。要让到达预测区域还没有订单的司机真正满意,可能又要做兜底的补贴奖励,由平台来担保准确率,这又衍生出复杂的奖励策略问题以及反作弊的问题。

再往下衍生,还有诸多问题要解决。

所以哪怕只是一个环节,就衍生出这么多问题,更不用说司机在订单生命周期里面临了几十个类似环节的潜在问题。

所谓路漫漫其修远兮,真正做好一个复杂场景下的用户产品,并不是想象中那么简单的事情。结合这四个关键问题的认知,还要对具体用户场景、用户需求、成本收益等多方面因素考虑,才能逐步解决司机产品的问题。

况且,这还只是单纯从用户视角看的产品问题。

从平台视角看,司机是服务提供者,我们还要为乘客提供确定性的服务,那边也有一大堆类似的问题,需要司机配合,这也会衍生出诸多运营导向的而非用户导向的产品问题要解决。例如可预测的临时爆发的需求(演唱会散场),就要面临复杂的调度运力的问题。

就先说这么多吧。这四个问题应当能对司机产品管中窥豹,了解大概。

本文来自微信公众号:刘言飞语(ID:liufeinotes),头图来自:东方IC。

Original Page: https://www.huxiu.com/article/298035.html

Shared from Pocket

 

9 条进阶命令,把 HomeBrew 打造成管理第三方应用的 App Store

03月04日

Minja

使用 Mac 的读者可能都听闻过 HomeBrew,这是一个简单易用的 包管理器,可以让你轻松下载、管理第三方应用。

可惜的是,我们读到的文章往往止步于 brew install 某某应用[^1](用 HomeBrew 安装应用)这一条命令。其实 HomeBrew 的作用远不只下载,我们多学几条命令,就可以把 HomeBrew 打造成一个第三方应用的 App Store,集搜索、下载和更新功能为一身,简洁高效。

搜索应用

就像在 App Store 中搜索应用一样,HomeBrew 也支持搜索,而且它会同时从 GitHub、应用官网等多个源头搜索,很容易找到需要的应用,无广告、速度快。

要搜索的话,请在终端输入这串命令:

brew search 应用名(一般需英文名)

我们可以看到 HomeBrew 提供了多种结果,如果只是单个应用名(如 squirrel),你可以用 brew install squirrel 直接安装[1],一般这类能直接下载安装的都是命令行工具。你还可以看到一类名字前带着 cask 的应用,它们需要换个命令来安装:

brew cask 应用名

就如其名字所代表的一样,brew cask(木桶)下载下来的是一个个打包好 .app 文件。

若想了解更多关于 cask 的内容,请阅读:

更新应用和清理旧版

有的应用不会自动更新(或默认不打开),我有个同学的 Chrome 现在就还停留在二十多个大版本之前。其实通过 HomeBrew 的命令,哪些应用需要更新一目了然,即使它们不提供自动更新,我们时不时去检查、更新一下也能保证应用处于最新版。

首先用下面的命令检查一下可更新的应用有哪些,由于我比较勤快,只有一个 imagemagick 不是最新版本 。

brew outdated

接下来更新一下可更新的应用。一般我会更新所有应用,所以我最常用的是这条命令:

brew upgrade

但有时我们不想更新所有应用,比如 Chromium 有个历史版本不禁用 Flash,我一直留着它以应对那些食古不化的网站,不希望 Chromium 更新到更高版本。此时我们可以在上面那条命令的基础上加上需要更新的应用名,避开不需要更新的应用:

brew upgrade 应用名

更新完后可以运行一下下面的命令,把应用的旧版本和缓存删除。

brew cleanup

如果你只是想看看有哪些应用可以清理,但暂时不需要处理它们,则可以通过这个命令一窥究竟:

brew cleanup -n

当然,有的应用缓存和旧版应用是有用的(比如可能保存了我的用户配置文件),那就不能一杆子打尽,而是像指定更新个别应用一样,指定需要清理缓存的应用:

brew cleanup 应用名

Tips:访问应用官网

有时我们不确定自己是否需要更新一个应用,比如,它的新功能我是不是需要?它的新版本适不适配我的系统?纠结这些,不如即刻去应用官网上一探究竟:

brew home 应用名

小结

电脑里的第三方应用越多,HomeBrew 的优势越明显。

如果只下载一个应用,可能径自前往其官网也不会觉得麻烦,但如果你每次下载第三方应用就要前往官网、每次更新都得去其菜单栏中寻找 update 按钮,那显然是不便的。HomeBrew 就为这些的零碎的操作提供了一个集中的管理办法。

学会了本文的几条命令,对你来说 HomeBrew 就不再是晦涩的命令行工具,而是一个简单好用的第三方应用版 App Store。

  1. 直接用 brew install 安装的并非「Squirrel 鼠须管输入法」

#应用推荐#Mac#macOS#效率工具#效率

Setup Swap File on Linux

Published on: Thu, Oct 2, 2014 at 3:25 pm EST

CentOS Debian Linux Guides Ubuntu

There will be times where you need to increase the responsiveness of your server to prevent out of memory issues. Out of memory issues happen when an application running on your server starts consuming a large amount of memory. Swap is designed as virtual memory, which uses your harddrive to store data that cannot be held in RAM. This tutorial will show you how to create a swap file, which should work under Ubuntu, CentOS, and Debian. This tutorial is not meant for any Custom ISO, but it is possible to follow along.

Step 1: Verify that swap does not exist

To prevent any issues during this tutorial, you will need to run the following to verify that a swap space is currently not active:

[code language=”plain”]free -m
[/code]

After running that command you should see something similar to this output:

 

 

 

If you see a value of 0 in the Swap section, then you can proceed to step 2.

Alternatively, you can run the following command to see if there is a configured swap file:

 

 

If you do not see any output from swapon, then proceed to step 2.

Step 2: Create swap file

You will need to choose a location for your file. In this tutorial, it will be stored at the root of the server. We will create a 2GB swap file by running the following command:

 

 

 

The dd command will produce output in a similar format to:

 

 

 

Next, verify that the file is located at the root of your Vultr VPS by running:

[code language=”plain”]ls / | grep swapfile
[/code]

Proceed if you see the swapfile file.

Step 3: Activate the swap file

Swap files are not recognized automatically. We will need to tell the server how to format the file and enable it so it can be used as a valid swap file. As a security measure, update the swapfile permissions to only allow R/W for root and no other users. Run:

 

 

 

The permission change can be verified by running the following command:

 

 

 

You will see a file display:

 

 

 

Next, tell the server to setup the swap file by running:

 

 

 

After running it, you will see the following output:

 

 

 

If everything is shown as above, you are now ready to move on to the next step.

Step 4: Turn swap on

Once your file is ready to be used as swap, you need to enable it by running:

 

 

You can verify that the swap file is active by running the free command again.

 

 

If Swap shows something other than 0, then you have successfully setup swap.

Step 5: Enable swap on reboot

By default, your server will not automatically enable this new swap file. To enable it on boot, you can update the /etc/fstab file. Any text editor will suffice. In this example, I will be using nano.

 

 

Add the following line at the end of the file:

 

 

Save and close when you are finished editing the file. We are all done!

目前来说一款插件解决问题 Evernote 同步 

具体同步如下:

1.是否支持图片(看到即支持)

2.格式支持:表格

测试 测试1 测试2
1
1
1
1
1
1

3.是否支持修改(看到下方有“我是修改测试”那即表明支持修改后同步)

我是修改测试

2017年7月16号,儿子两周岁,一岁的时候,爸爸妈妈给你选了你的爱好小黄人,到了两岁才发现你喜欢的是小猪佩奇.
很高兴2岁的你有了明显的喜好
喜欢车,你会喊car
喜欢佩奇,你会指着他喊 奇~
虽然你会说的话不多
但是你爱憎分明
喜欢的事情,你会说
不想要的东西,你会大声说不要
虽然老爸经常说的话你都不要不要,但是我还是很开心
望你一生如此开心

今年春节档电影看了两部西游伏妖篇乘风破浪。两个电影都带着抄袭的影子

西游伏妖篇,各种星爷抄袭着自己的段子,自己的风格,自己的故事自己的音乐。甚至连小鲜肉吴亦凡也各种抄袭着星爷说话的语气
乘风破浪,还未看前查了一下豆瓣以及知乎,就被冠以抄袭新难兄难弟,是否抄袭不知道,因为我没看过所谓被抄袭的那部电影,不过听说很经典,准备去看看。

乘风破浪这部电影里面满满韩寒自己的元素在里面,亭林镇 拉力赛 他用别人讲过的故事,讲着自己的故事,就如让这个故事讲给了不知道新难兄难弟的我听。

抄袭与否我不做评论,单纯电影来说,我觉得春节档这部电影应该是最好看的。

今天大年三十,很久没回老家了。
老家微信支付还没普及,很多地方还不能微信支付,特别典型的三四线城市的样子,不大有点脏。
老家还是那个老样子,甚至在奶奶家找到一台我5,6岁时候的一台遥控汽车,而现在这台遥控汽车可以拿给我的儿子玩。
老家还是那个老样子,每当我有一些负面的东西的时候,老家都能很好的帮我清理掉他。
可能这就是老家,这个词所代表的意义吧
很好,有一些东西变得很快,但是有一些一直都没变化。喜欢这样的变化中的不变。

租用的VPS马上到期了,我还是没折腾明白如何迁移之前的博客,那么就让博客留在他该在的位置吧。
世界本来就该如此,你费尽心思折腾来的,或许不一定是你该拥有的东西。
2017

1198x375

好久没有看过足球了,??德国 VS ??意大利 没有烧烤、没有啤酒、没有叫喊,现在足球跟我少了一些交集。足球是群体运动,看球也必须是群体的活动。好了不说了加时赛马上结束了估计要点球大战了,德国队好运