Akawa

ETY001的博客

在经过昨天的3小时马拉松出炉基础版 AnonymousDiscussions 后,今天进行了以下的功能完善和bug修正:

  1. 首页所有OS已经有了分页功能

  2. 评论也有了分页功能

  3. 增加了OS的点击数统计

  4. 首页可以看到每个OS的评论数

  5. 调整了首页OS列表的样式

  6. OS详情页加入了点击数显示

  7. OS详情页加入了回到页顶部功能

  8. 使用伪静态,URL显示优化

  9. 修改了部分文字语法和文字表述

  10. 新发布评论后的跳转问题

  11. OS的发布时间显示方式进行了调整

欢迎继续来发OS,网址很好记:http://ohshit.cc  ~~~

archlinux更新了下,居然在firefox中用不了了,在qt程序中都能使用。我的桌面环境是xfce

1
http://fcitx.github.com/handbook/faq.html#ctrl_space

发现是/etc/gtk-2.0/gtk.immodules和gtk-query-immodules-2.0的内容不一样,里面是空的!估计是更新的时候被清空了…

解决方法将gtk-query-immodules-2.0的输出弄到/etc/gtk-2.0/gtk.immodules中。

1
gtk-query-immodules-2.0 | sudo tee /etc/gtk-2.0/gtk.immodules

logout,再login,ok了

轉自:http://hi.baidu.com/zechen11/item/c1f6ff0e46c678e3fe240d2f

參考下這裏:https://fcitx-im.org/wiki/Input_method_related_environment_variables/zh-cn

另外,在archlinux下安裝時,安裝fcitx-im即可,另外安裝fcitx-configtool可以使用界面模式來配置fcitx。

转自:http://hi.baidu.com/piaoshi111/item/9ffdb6ddbe2ca24adcf9be38

也许你从来没有听说过柔性数组(flexible array)这个概念,但是它确实是存在的。
C99中,结构中的最后一个元素允许是未知大小的数组,这就叫做柔性数组成员,但结
构中的柔性数组成员前面必须至少一个其他成员。 柔性数组成员允许结构中包含一个大小可
变的数组。sizeof返回的这种结构大小不包括柔性数组的内存。包含柔性数组成员的结构用
malloc ()函数进行内存的动态分配,并且分配的内存应该大于结构的大小,以适应柔性数组
的预期大小。

阅读全文 »

转自:http://www.cnblogs.com/grenet/archive/2010/03/08/1680655.html(文章后面的评论也不错)

在很多网站系统(如CMS系统,SNS系统等),都有“站内信”的功能。

“站内信”不同于电子邮件,电子邮件通过专门的邮件服务器发送、保存。而“站内信”是系统内的消息,说白了,“站内信”的实现,就是通过数据库插入记录来实现的。

“站内信”有两个基本功能。一:点到点的消息传送。用户给用户发送站内信;管理员给用户发送站内信。二:点到面的消息传送。管理员给用户(指定满足某一条件的用户群)群发消息。点到点的消息传送很容易实现,本文不再详述。下面将根据不同的情况,来说说“站内信”的群发是如何实现的。

第一种情况,站内的用户是少量级别的。(几十到上百)

这种情况,由于用户的数量非常少,因此,没有必要过多的考虑数据库的优化,采用简单的表格,对系统的设计也来的简单,后期也比较容易维护,是典型的用空间换时间的做法。

数据库的设计如下:表名:Message

ID:编号;SendID:发送者编号;RecID:接受者编号(如为0,则接受者为所有人);Message:站内信内容;Statue:站内信的查看状态;PDate:站内信发送时间;

如果,某一个管理员要给所有人发站内信,则先遍历用户表,再按照用户表中的所有用户依次将站内信插入到Message表中。这样,如果有56个用户,则群发一条站内信要执行56个插入操作。这个理解上比较简单,比较耗损空间。

某一个用户登陆后,查看站内信的语句则为:

Select * FROM Message Where RecID=‘ID’ OR RecID=0

第二种情况,站内的用户中量级别的(上千到上万)。

如果还是按照第一种情况的思路。那发一条站内信的后果基本上就是后台崩溃了。因为,发一条站内信,得重复上千个插入记录,这还不是最主要的,关键是上千乃至上万条记录,Message字段的内容是一样的,而Message有大量的占用存储空间。比方说,Message字段有100个汉字,占用200个字节,那么5万条,就占用200×50000=10000000个字节=10M。简单的一份站内信,就占用10M,这还让不让人活了。

因此,将原先的表格拆分为两个表,将Message的主体放在一个表内,节省空间的占用

数据库的设计如下:

表名:Message

ID:编号;SendID:发送者编号;RecID:接受者编号(如为0,则接受者为所有人);MessageID:站内信编号;Statue:站内信的查看状态;

表名:MessageText

ID:编号;Message:站内信的内容;PDate:站内信发送时间;

在管理员发一封站内信的时候,执行两步操作。先在MessageText表中,插入站内信的内容。然后在Message表中给所有的用户插入一条记录,标识有一封站内信。

这样的设计,将重复的站内信的主体信息(站内信的内容,发送时间)放在一个表内,大量的节省存储空间。不过,在查询的时候,要比第一种情况来的复杂。

第三种情况,站内的用户是大量级的(上百万),并且活跃的用户只占其中的一部分。

大家都有这样的经历,某日看一个网站比较好,一时心情澎湃,就注册了一个用户。过了一段时间,由于种种原因,就忘记了注册时的用户名和密码,也就不再登陆了。那么这个用户就称为不活跃的。从实际来看,不活跃的用户占着不小的比例。

我们以注册用户2百万,其中活跃用户只占其中的10%。

就算是按照第二种的情况,发一封“站内信”,那得执行2百万个插入操作。但是其中的有效操作只有10%,因为另外的90%的用户可能永远都不会再登陆了。

在这种情况下,我们还得把思路换换。

数据库的设计和第二种情况一样:

表名:Message

ID:编号;SendID:发送者编号;RecID:接受者编号(如为0,则接受者为所有人);MessageID:站内信编号;Statue:站内信的查看状态;

表名:MessageText

ID:编号;Message:站内信的内容;PDate:站内信发送时间;

管理员发站内信的时候,只在MessageText插入站内信的主体内容。Message里不插入记录。

那么,用户在登录以后,首先查询MessageText中的那些没有在Message中有记录的记录,表示是未读的站内信。在查阅站内信的内容时,再将相关的记录插入到Message中。

这个方法和第二种的比较起来。如果,活跃用户是100%。两者效率是一样的。而活跃用户的比例越低,越能体现第三种的优越来。只插入有效的记录,那些不活跃的,就不再占用空间了。

以上,是我对群发“站内信”的实现的想法。也欢迎各位提出自己的建议,大家互相借鉴,共同进步。

首先PS一句:出差加班的节奏真心不适合同时看着电视,尤其是看到一部戳中软肋的情感片。

忘记哪次去看电影的时候,记的电影开始前的预告片中看到过《分手合约》的,不过印象中预告片给我的感觉更像是爱情喜剧,但显然我是错了。

电影讲述了一个爱情故事,头20分钟各种无力,但是也正是这些无力的铺垫,使得爱情看上去如此的奢侈。女孩提出分手合约,大家都认为是女孩太势利,貌似有些映射当前的意思,可能大家都认为爱情是一件奢侈品,你有时候不得不放弃。

但也许爱太深,男孩并没有放弃,他在努力,努力去完成女孩想要的。合约马上到期,眼看一切都顺理成章的向着幸福滑行的时候,真相才接踵而至,女孩之所以5年前选择离开是因为自己得了癌症。也许你和我一样在感慨剧情的狗血,这么容易就被猜到了,但是我觉得我们有时候的确有些理智了,为什么非要把一件艺术品用理性的思维去思考呢?

阅读全文 »

知道我最喜欢我的808除了拍照以外的另一个功能是什么吗?那就是呼吸灯。从5800w开始我就很喜欢那个呼吸灯,以至于后来买雷蛇的鼠标也是买的带CF标识的呼吸灯的那款,再后来就有了808。

开始有人琢磨我到底是要在写些什么了。其实我也不知道我自己要写些什么,那为何不随着自己的思绪,跟着呼吸灯微弱的节奏慢慢感受自己的心跳,随心所欲想到哪就写到哪呢?

这也许就是为何我喜欢呼吸灯的缘故吧,在漆黑的夜晚,能有一个微弱的灯光点亮,实在是多了一分细腻的感觉在里面。跟着呼吸灯让自己放慢节奏,感受下自己的内心的所思所想。有时候就是会这样慢慢开始胡思乱想,开始做各种假设。假如,我在初二没有选择接触黑客的自由的思想,那现在的我是否还会有当下的烦恼?假如,我当时选择了去上国防生,那是不是现在我的人生又会有别样的烦恼?假如……这样的假如真的太多了,但是既然我选择了自己的道路,那就坚定的把他走下去吧,谁能知道将来呢?就让我像呼吸灯一样,不知道自己什么时刻就会没电灭掉,但是依旧按照自己的节奏,慢慢的,安静的去完成自己的事情。

但是,也许这就是人类思想的强大之处,可以给一个物体赋予生命,让它变的像人一样会思考,其实这只不过是人类自己在思考自己罢了。就像我现在说的呼吸灯,也许就是我的一个缩影,在自己选择的道路上坚持,虽然天资不聪颖但是懂得努力,知道笨鸟先飞,但也有不懂的变通的致命弱点。突然间发现了自己是在写什么了会觉得再写下去就已经很无聊了,也许这就是我的一种生活态度。

让自己过的不一样些,逐渐的把自己拨回到表盘的应该位置,想想如何修理下已经程序化的大脑让它更近人类而不是机械!

很久没有入侵过服务器了。这次入侵的起因是学校社团的服务器页面遭到挂马了,但是有意思的是,挂马的iframe代码时有时无,在服务器上查看源代码也没有问题。于是排除了直接改源文件的可能和DNS遭到劫持的可能。

看了下挂马的地址是跟自己服务器同C段的,因此猜测可能是遭到了ARP欺骗攻击,但是不确定是有人故意攻击我的服务器还是属于批量攻击。于是目标就先锁定这台挂马的服务器。

扫描了端口,开了不少,21,80,3389一些常见的端口都开着,3389了下,看到是win2003。百度了下IP,么有有用信息,google了下,发下了这个IP上绑定了的域名,对该域名进行whois,发现了很多信息,逐步的又发现了很多关于这个域名注册者的信息,有gmail邮箱,居住地信息,在网络上的活动痕迹,可能还有工作地点信息和生日年份,简单的尝试猜解gmail邮箱失败。换个思路,访问下IP看看下面是什么站,由于运营商封掉了直接访问IP,因此我用我自己的域名绑定了下这个IP,访问发现是个N点虚拟主机管理系统,果断搜索引擎看看默认后台和账号,然后运气很好的就进入了N点的后台。

接下来就是建立个虚拟主机,配置他支持.net,这样果断上一个webshell,然后就是一通提权尝试。。。经过了6个小时的尝试失败了,常用的提权的路都试过了,由于很久没有搞过了,手头也没有能用的本地溢出,已是凌晨两点多,睡觉先。。

一觉醒来,回到N点看了下,发现貌似我可以配置应用池,果断配置成本地,然后再去webshell里执行添加用户的命令,成功,拿到administrator权限了。

剩下的事情就是简单清理下战场,然后上3389,下载360急救箱进行查毒(尼玛,100多个病毒啊。。还是两个用户的,看来至少进来过两个人了。。),自己写个C程,替换掉粘滞键那个程序,修改N点的默认密码,添加了个N点的隐藏管理员,收工,貌似清完病毒后,我的网站没有再出现过挂马代码,再观察段时间吧,到QQ安全管家网站申诉下网址安全了。

最后总结下:

1、尽量避免用windows主机吧,虽然配置下也挺安全,但是真正下工夫配置的有几个呢,很多人都是保持默认的,相比在默认情况下,linux可能会相对安全些。

2、即使买了服务器空间不用,或者只是买了测试,也不要保持默认的密码好吧,你这是对于自己邻居的危害啊!

3、这次不是个针对我的网站的定向的攻击,因为在尝试提权的6个小时里,我看过netstat和进程,发现这台机器还在尝试批量攻击别的服务器,所以应该是病毒行为。

4、没有了,就是不要再遇到这种蛋疼的事情了,大好的周末又泡汤了。。。看书去。。。。

我的个人blog服务器已经成功从digital ocean转移到aws ec2 micro。

试用一年后再转回digital ocean。

最近遇到一個bug,調試了很久了,沒找到原因,現象就是一個input框綁定了change事件,但是事件在IE9下面不觸發,不過如果用F12的工具逐行執行,卻又能觸發.後來因為無意中調出一個報警,報警內容如下:

SCRIPT5007: 无法获取未定义或 null 引用的属性“b”

才想到可能是js載入早於input框的載入,導致的事件綁定失敗,調整載入順序后,問題解決。

生活混亂感了好幾個月,最近貌似是有點頭緒了,應該是多個棘手的事情摻雑在了一起,並且還都暫時無解。

今天算是理了理工作上的混亂,感覺很大程度上還是自己的技術遇到了瓶頸,並且看不到未來,沒有指路的人,只能自己摸索,關鍵摸索的是別人已經走過的路,自己還不知道怎麼摸索,這就更讓我窩火。總結總結現在的水平,發現自己應該處於一個PHP初級到中級的進化的路上。

我對於PHP的劃分差不多就是四級,入門、初級、中級、高級。所謂的入門就是CRUD了。

初級就是框架使用,接觸過一些項目。

中級就是對中型或者大型的項目有實施經驗,這裡面就包括了怎麼應對大數據和大訪問量的問題,而這些東西要積累經驗,我覺得也就是得去像百度、淘寶這樣的地方,才有機會接觸到什麽是大數據。

高級就是通讀過php的源代碼,能寫出不錯的php擴展,對於php的內存管理等一系列核心的東西了如指掌。

進化總是伴隨著痛苦和迷茫,就像現在,技術上處於孤立的狀態,雖然這種狀態從我小學開始接觸計算機的時候就已經是這樣的了,一直自己一個人在摸索,估計要是沒有搜索引擎的話,我也許早就跳槽學別的了,現在想想還真是有些痛恨搜索引擎能讓我找到我之前遇到的問題的答案,不過貌似凡是能搜索到答案的問題都不是問題。。

對於技術瓶頸怎么克服,表示暫時還沒有啥好的解決方案,先完成幾個手頭想做的事情吧,一個是仿IFTTT(儘管這個想法是我在IFTTT出現前我就有的,誰讓IFTTT先出現了,只能叫做仿IFTTT了),一個是仿Mailinator。。。

0%