mojang正式被微软收购

一直想要写一篇关于Mojang AB被微软收购之后情况的文章,但是一直没有什么时机。

在大概19小时之前,mojang和微软确认微软收购mojang已经完成。收购的最终成交价在惊人的25亿美元。随着交易的完成250名员工被正式纳入微软工作室,与此同时作为创始人的Markus ‘Notch’ Persson、Carl Manneh 以及Jakob Porser离开了Mojang。


 

  • Markus ‘Notch’ Persson:Minecraft的创始者。也是Mojang AB原来的所有者以及创始者。大约在一年多以前停止参加Minecraft的开发,因为他认为这任务对于他个人来讲过于沉重
  • Carl Manneh:原Mojang AB的创始人之一以及CEO。
  • Jakob Porser:Minecraft创始者之一,也是开发者之一。是Notch的好友之一。

现在Mojang AB已经被微软收购了,未来的Minecraft前途也是值得考虑的。众所周知,在Minecraft玩家社区里面有两套著名的API:一个是bukkit服务器的插件API,另一套就是forge的Mod API。

前一段时间Mojang AB收购了Bukkit服务器,bukkit服务器的开发者,天才少年Dinnerbone也加入了Mojang的开发团队。但是由于著作权等的原因,bukkit实际上是被完全的停止了。微软收购了Minecraft之后bukkit的开发可能会更加不可能。

另一个影响力比较大的API就是forge了。在确认minecraft被微软收购的时候forge团队的创始者之一离开了开发,但是forge团队还是一直坚持着forge的开发。forge团队的核心成员现在是依靠forge团队的收入来维持生活,而forge团队的收入基本上就是ad.fly以及用户的微薄的捐款。现在来看短时间内forge团队不会因为收入问题而解散。

值得担心的是微软的收购对于minecraft使用java编写这个事实的影响程度如何。众所周知的事情是java是基于java字节码的,这给了java很容易被反编译的特性。正是这个特性才导致了mcp,forge以及bukkit的产生。java当然不是微软他家的东西了,微软很可能在未来的版本不使用java编写而是用c#,不过这个不是什么严重的问题。毕竟c#也是很容易反编译的语言。但是微软很可能在每次发布的时候修改minecraft的混淆名。这样的话将会给forge团队增加巨量的工作。这个对于forge可能是毁灭性的打击。

此外,微软很可能在minecraft游戏内部引入正版验证。众所周知,minecraft的正版验证是由启动器完成的,游戏内部不会去管是否是正版这件事情。在微软收购之后游戏内部的正版验证很可能被引入,这对于mod开发也将会是很大的挑战。

minecraft的命运将会如何,以后minecraft会不会还是我们热爱的minecraft,这个还需要时间来确定。

 

国产操作系统,现在还太早了

本来不打算评论国产操作系统的,但是ccf这一期的技术动态里面提到的“中央要求国产系统每年替换15%Windows”让人不得不去想国产操作系统。最近一段时间国产操作系统一直被媒体一次次的推向公众关注的焦点,但是这些基于linux的国产pc操作系统或者基于android的国产手机操作系统实在是太不成熟了。
一直以来一提到国产的操作系统基本都是说红旗Linux,但是随着红旗的破产国产linux操作系统的领头羊倒下了。国产操作系统生存不下去的原因就是因为没有人使用,虽然政府采购能够在一定程度上维持公司的运作,但是完全的完成一个操作系统的生态环境是不可能的。如果操作系统不能被市场接受,撬不动大量的资金流入国产操作系统生态圈那是不可能的。
中国人长期以来习惯了盗版的windows,突然让他们转到Linux下面就是完全不可能的事情。各种国产的Linux操作系统也是在努力模仿着windows xp。而大量的政府网站还是只支持IE,许多政府的应用程序也是只支持Windows xp;这些问题对于资金充裕的中央机构可能是非常容易的事情,但是对于资金不甚充裕的基层单位基本就是不可能的。那些没有资金支持的基层单位可能不得不放弃已有的某些程序来使用那些国产Linux。真正推广国产Linux系统难度还是很高的。
至于国产手机操作系统,这些也无非是Android的UI和服务的定制系统。它归根结底还是Android,虽然只是把Google踢掉了。现在Google一直在做Android的开源硬件对于这些系统厂商将会是非常大的威胁,有可能以后国产手机厂商连去定制系统的钱都没有了,完全沦为生产硬件的富士康。
虽然政府现在大力扶持国产操作系统,但是一旦失去支持,这些系统是不会成气候的。

Discuz中session机制讲解

本文章转载自网络,但是原始来源不详,如果侵犯到您的权益,请告之删除文章。

 


在Discuz! X中一如继往的,SESSION 并没有使用 PHP 自带的 SESSION 机制,而是系统的一套自带的机制。

在数据库中可以看到有两个 SESSION 表:

  • 一个是pre_common_adminsession,是管理员登录后台的 SESSION 表;
  • 另一个是 pre_common_session 表,是所有用户在前台浏览页面时的 SESSION 表。

这两个表都是内存表(内存表的读写速度远高于 MYISAM 表及文本文件)。

在 Discuz! X 中 SESSION 与 COOKIE 是分不开的,因为 SESSION 就是从客户端读取的 COOKIE ,
然后由浏览页面时触发相关的函数执行,再写入数据库 SESSION 表。

我以登录流程为例来讲解程序具体是如何执行的。
在前台首页,点击登录后,弹出一个登录窗口,填写好数据后,提交。form表单提交的 URL 是:

http://ux.com/member.php?mod=logging&action=login&loginsubmit=yes&floatlogin=yes&inajax=1

数据提交到了 member.php 文件中,在程序中可看到下面的代码:

$mod = !in_array($discuz->var['mod'], $modarray) ? 'logging' : $discuz->var['mod'];   //mod的值即是接下来加载的php页面 
define('CURMODULE', $mod); 
$modcachelist = array('register' => array('modreasons', 'stamptypeid', 'fields_required', 'fields_optional', 'ipctrl')); 
$cachelist = array(); 
if(isset($modcachelist[CURMODULE])) { 
    $cachelist = $modcachelist[CURMODULE]; 
} 
$discuz->cachelist = $cachelist; 
$discuz->init(); 
runhooks(); 
require DISCUZ_ROOT.'./source/module/member/member_'.$mod.'.php';  //完成程序的包含操作

打开source/module/member/member_logging.php文件,是一个类,在类的前面可看到下面三句代码:

$ctl_obj = new logging_ctl(); 
$method = 'on_'.$_G['gp_action'];  // $_G['gp_action'] 等于action的值即 login 
$ctl_obj->$method();   //$ctl_obj->on_login(); 

在类中可找到login方法,在方法中,大约 56 行有下面一个判断语句:

if(!submitcheck('loginsubmit', 1, $seccodecheck)) { 

判断语句是当游客浏览时,submitcheck 函数的返回值是假,取反,为真。
当用户登录时,程序走的是else部分,在里面可看到下面五句代码

} else { 
            $_G['uid'] = $_G['member']['uid'] = 0; 
            $_G['username'] = $_G['member']['username'] = $_G['member']['password'] = '';    //变量赋值 
            $result = userlogin($_G['gp_username'], $_G['gp_password'], $_G['gp_questionid'], $_G['gp_answer'], $_G['setting']['autoidselect'] ? 'auto' : $_G['gp_loginfield']);  //从数据库查询用户数据,并返回相应的信息 
   
            if($result['status'] > 0) {  //状态值大于 0 ,说明有此用户,可以登录 
                setloginstatus($result['member'], $_G['gp_cookietime'] ? 2592000 : 0);  //设置登录状态,即是写 COOKIE 操作,COOKIE 中的数据即是 SESSION 中相应的数据,但此函数并不负责写 SESSION 的操作 

我们来看一下 source/function/function_login.php中的 setloginstatus 函数,是普通的写 COOKIE 操作,不再具体讲解:

function setloginstatus($member, $cookietime) { 
    global $_G; 
    $_G['uid'] = $member['uid']; 
    $_G['username'] = $member['username']; 
    $_G['adminid'] = $member['adminid']; 
    $_G['groupid'] = $member['groupid']; 
    $_G['formhash'] = formhash(); 
    $_G['session']['invisible'] = getuserprofile('invisible'); 
    $_G['member'] = $member; 
    $_G['core']->session->isnew = 1; 
   
    dsetcookie('auth', authcode("{$member['password']}\t{$member['uid']}", 'ENCODE'), $cookietime, 1, true);   //authcode加密 
    dsetcookie('loginuser'); 
    dsetcookie('activationauth'); 
    dsetcookie('pmnum'); 
} 

到这里可以说是登录流程大部分已经走完,但是 COOKIE 不清除时,会一直存在于客户端,如果超时,程序中会在判断弃用此 COOKIE,并重新写入。

下面我们来看一下 DZX 中 SESSION 操作的类,在 source/class/calss_core.php 文件中:
程序中每次请求都会加载 SESSION ,这是由核心类 discuz_core 中的 _init_session 方法来执行的,此方法被置于 类的 init方法中,说明每次加载类,会自动将 SESSION 写入。

function _init_session() { 
 
    $this->session = new discuz_session();   //创建 SESSION 类 
 
    if($this->init_session) { 
        //从 COOKIE 中读取数据 
        $this->session->init($this->var['cookie']['sid'], $this->var['clientip'], $this->var['uid']); 
        $this->var['sid'] = $this->session->sid; 
        $this->var['session'] = $this->session->var; 
        //判断 SID 是否相等,不等,说明是多个用户在同一主机上登录网站,需要重新写 COOKIE 
        if($this->var['sid'] != $this->var['cookie']['sid']) { 
            dsetcookie('sid', $this->var['sid'], 86400); 
        } 
 
        if($this->session->isnew) { 
            if(ipbanned($this->var['clientip'])) { 
                $this->session->set('groupid', 6); 
            } 
        } 
 
        if($this->session->get('groupid') == 6) { 
            $this->var['member']['groupid'] = 6; 
            sysmessage('user_banned'); 
        } 
        //UID 不为空,且需要更新 SESSION 或是 SESSION 超时,更改用户状态,需要用户重新登录 
        if($this->var['uid'] && ($this->session->isnew || ($this->session->get('lastactivity') + 600) < TIMESTAMP)) {                $this->session->set('lastactivity', TIMESTAMP); 
 
            $update = array('lastip' => $this->var['clientip'], 'lastactivity' => TIMESTAMP); 
            if($this->session->isnew) { 
                $update['lastvisit'] = TIMESTAMP; 
            } 
            DB::update('common_member_status', $update, "uid='".$this->var['uid']."'"); 
        } 
 
    } 
} 

操作 SESSION 的类是 discuz_session ,我们看这个类里面的两个方法:

//此函数负责产生新的 SESSION,但并不负责写入数据库 
    function create($ip, $uid) { 
//创建SESSION,执行插入数据,由随机函数产生一个六位随机数即是session的唯一值时间为当前时间,sid为cookie中的sid 
        $this->isnew = true; 
        $this->var = $this->newguest; 
        $this->set('sid', random(6)); 
        $this->set('uid', $uid); 
        $this->set('ip', $ip); 
        $this->set('lastactivity', time()); 
        $this->sid = $this->var['sid']; 
   
        return $this->var; 
    } 
//此函数负责更新 SESSION 
    function update() { 
        if($this->sid !== null) { 
   
            $data = daddslashes($this->var); 
   
            if($this->isnew) { 
                $this->delete(); 
                DB::insert('common_session', $data, false, false, true); 
            } else { 
                DB::update('common_session', $data, "sid='$data[sid]'"); 
            } 
            dsetcookie('sid', $this->sid, 86400); 
        } 
    } 

至此我们知道了 SESSION 插入数据库的具体函数,与 COOKIE 的联系,但还不清楚是如何触发此操作的。
打开 source/function/function_core.php 文件,找到函数,updatesession ,此函数负责更新 SESSION :

function updatesession($force = false) { 
   
    global $_G; 
    static $updated = false; 
    if(!$updated) { 
        $discuz = & discuz_core::instance(); 
        foreach($discuz->session->var as $k => $v) { 
            if(isset($_G['member'][$k]) && $k != 'lastactivity') { 
                $discuz->session->set($k, $_G['member'][$k]); 
            } 
        } 
   
        foreach($_G['action'] as $k => $v) { 
            $discuz->session->set($k, $v); 
        } 
   
        $discuz->session->update(); 
   
        $updated = true; 
    } 
    return $updated; 
} 

我们在程序源码中搜索此函数,可以看到在很多的模板中都有下面一句代码:

{eval updatesession();} 

浏览页面时将触发此函数,并将 SESSION 写入数据库。

整理一下思绪:
第一步:用户登录,程序将 COOKIE 写入客户端,这些 COOKIE 即是 SESSION 的部分数据,如SID、IP、TIME,不包含用户名、密码等关键信息。
第二步,登录成功后,程序会自动刷新页面,向服务器再次发送请求,服务器加载 discuz_core 核心类,并从 COOKIE 中读取到 SESSION 的相关信息,但还没有写入数据库。
第三步,核心类加载完成,程序继续执行,最后加载模板,触发 updatesession 函数,SESSION 被写入数据库。

minecraft mod教程:实体1-初识实体

终于这个教程来到了我最不愿意讲的地方了,拖了好久教程还是要写的。今天就写一点最基本的。讲一讲minecraft中实体的概念。

简单的讲,在游戏中所有的不是方块的东西都是实体。矿车、船、生物、玩家是实体,经验球是实体,掉落的物品也是实体。就和每一个方块都有一个对应的物品一样(注册方块的时候系统为我们自动注册了这个方块的物品。所以你可以在物品栏里面见到这个方块)。每一个物品都有对应的实体类型,这样物品掉落之后你就可以出现这个物品的掉落物的实例,然而这是不可能的,minecraft当然会只定义一个类来描述所有的掉落物实体本身。

讲到实体就不得不提NBT了。NBT是一系列树状的二进制标签来描述一个实体或者方块的附加数据。如果你熟悉minecraft游戏本身的话你可能知道NBT是怎么回事,如果你不知道的话那么请通过NBT Edit或者一些地图编辑器来熟悉一下NBT是什么样的一些数据。NBT里面能够包含各种各样的数据,它就像是二进制版的json。

游戏中的实体就是继承自net.minecraft.entity.Entity的家伙们。每一个实体都会有一个自己的ID,通过这个ID,实体被串联成了一个链表。实体还包含了大小,位置,旋转,速度,AABB盒(一个碰撞盒。minecraft使用AABB盒来检测碰撞。在空间中确定一个立方体只需要两个点的坐标(就像领地插件),这个被确定出来的立方体就是AABB盒。你可以在调试模式里面显示实体的碰撞盒。),所在世界,所在维度等信息。当实体所在区块离玩家过远的时候,区块会被卸载,区块中的实体的信息也会被储存在NBT里面存储在区块的信息里面。

以上就是一些最基础的信息。下一节的教程我们将会学习如何创建一个实体。

windows下的Git服务器搭建

最近打算搭建上一台Git服务器来实现团队内部的代码的共享什么的。研究了许多方案下面都介绍一下。

搭建Git服务器最方便的还是使用Linux操作系统来搭建,毕竟Git就是为了Linux而生的。但是鉴于我手头上只有Windows Server所以下面只介绍如何在Windows Server上搭建Git服务器。

最直观的想法就是在Windows上面模拟一个Linux环境就好了。在Windows上面模拟Linux环境如果不使用虚拟机的话大概cygwin是没得跑了。这样做一个明显的缺点就是整个系统太过于冗杂。cygwin需哟大量的磁盘空间才能运行。并且如果不使用额外的服务器的话大概只能通过SSH来连接Git。但是好多主机防火墙为了安全都会禁用SSH连接。如果更改端口的话Git GUI等工具就无法使用。所以这不是一个良好的解决方案。

找了许久找到了一个很好地Git服务器。Bonobo.Git.Server是一个人基于.net 4.5的Windows Git服务器。支持WEB管理以及多国语言,是搭建Git服务器的不二之选