Unity 3 Feature Preview – Image Effects from Unity3D on Vimeo.

Can’t wait to see it.

Most important for me, has Unity3 enhanced the Chinese Character Display ?

It’s really stupid to using texture to display characters.

And I have to using cocos2d instead because of this.

Random Posts

• OSX Terminal(终端) 使用快捷键
• 涂鸦
• Ubuntu 9.10(karmic) 升级源(sources.list)
• [转]软件公司是怎么死掉的

原文地址 http://techcrunch.com/2010/05/16/iphone-app-sales-exposed/

摘录其中一段

However, when the top 10% of the most successful apps are removed from the data set, the numbers skew much lower, giving a far better impression of what the iPhone industry looks like for most developers. In this scenario, the average sales were 11,625 total units, averaging 44 copies/day. Approximately 23% of apps sold less than 1000 units from launch (ranging from 12 to 370 days in the App Store). Further, 56% of apps sold less than or equal to 10,000 units, while 90% sold less than 100,000 units, with the remaining 10% achieving sales of 127,000 – 3,000,000 units.

Related Posts

• iBook Page Curl Animation 翻页效果
• now or never
• What is iPad All About?
• 10年之前

内容包括:招募队员,确立项目到测试发布,各位慢慢品味.

原文地址 http://developer.valvesoftware.com/wiki/Making_a_Mod

Starting out

Lets start by looking at how to assemble a team. The guiding rule here is to keep it small. Managing a team of people is a full-time job, even when all the team resides in the same building. If you’re dealing with an on-line team, you can easily spend all your time managing it, and that means you won’t be spending any time on making your mod. Adding more people to the team doesn’t mean more work will get done. The more people you have, the more time spent managing them. Team Fortress’s core team was 3 people. Counter-Strike‘s core team was one person.

When looking for team members, try to only hire people you absolutely cannot survive without. Your first instinct might be to hire anyone who can code, or model, or make maps, and so on. But for your first version, you probably won’t need more than one person for each area of your mod (code, sound, models, maps). You may not even need any new models, sounds, or maps. Don’t hire anyone until you’ve seen examples of their work. Make sure they’ve actually finished things. If they’re a modeler who’s done 20 models, but they’re all half-finished, you don’t want them.

Mod design

As a mod author, the most useful question you can ask yourself is “Why should someone play my mod?” It’s a hard question to answer truthfully, but if you can answer it well, you’re on the right track. Think about what other mods are out there, and what they offer. Does your mod offer something new to the players? Is what you offer enough to entice players who are busy playing other mods? Even if you can’t answer this question, just thinking about it will probably help your mod.

Compete with gameplay

You have power commercial developers don’t: You don’t have to worry about the commercial viability of new gameplay styles. Commercial developers have to worry about appealing to retail, breaking even, and other nasty things, which is why most games are slight modifications on already proven gameplay. But you don’t. You can try out truly new gameplay ideas that just might become the Next Big Thing. This is your edge over commercial developers. Make your job easier by concentrating on this edge, and don’t spend your time trying to compete in the areas that commercial products are strong in. Most mods can’t compete on a content level (maps, models, sounds, etc) with commercial products. They’ve got teams of artists with years of experience. Beat them with your gameplay. Players will play a mod that has very little in the way of new content, but has really fun gameplay. Something many people don’t realize is that Team Fortress 1 had almost no new art for a year after it was first released.

Release soon, release often

You have another power over commercial developers. You can release much, much faster and more often than they can. We’ve summarized this mod development philosophy with the phrase, “Release soon, Release often.” Commercial developers work for 2-3 years, release their game, and hope to god people like it. You don’t have to make that leap of faith. You can design your whole mod, write 25% of it and polish it to a playable state, then release it and begin getting feedback immediately. Then you can start adding the rest of your design piece by piece, at the same time rolling in the player’s feedback to the first version, and continue releasing every month or two. You’re in touch with your players at all times, so you’ll never be in the situation where you’ve spent a lot of time on something you’re not sure your players will like. The trick is to cut your mod up into slices. The initial version needs to be fun and playable, but doesn’t need every cool feature you’ve thought of.

Be careful. “Release soon” doesn’t mean releasing bad quality stuff, it just means doing your mod in small, polished increments. The first version of Counter-Strike didn’t have half of the features they have now. The CS team released a high quality, but not big mod. Over the past year, they’ve been regularly adding more and more features and, in response, their player base has just continued to grow and grow.

Different is not always better

When thinking about your game design, don’t fall into the trap of believing that “Different is Better.” There’s no reason to rewrite the shotgun code and have a new shotgun model if it doesn’t impact your game in any interesting way. Keep in mind the first question, “Why should someone play my mod?” The answer, “My mod has a new combat system, and a new movement system,” isn’t necessarily a good answer. So your combat system is different that Half-Life’s. OK… but is it better? Does it make your mod more fun to play? Does a new movement system make the game more fun? Player’s are used to existing systems, and making them learn another one needs to be worth it for them. So before you think about changing something, make sure you know you’re changing it for the better, and that it’ll make your mod more fun. Don’t be afraid to just leave something the same as it was in Half-Life.

Realistic goals

Create realistic goals for yourself. Think about how long it takes a commercial developer to make an FPS shooter with 10 weapons. If your mod is going to have 40 weapons, you’re making life really hard for yourself. The thing to keep in mind here is “Quality over Quantity.” Players would far prefer to have 10 unique, well balanced, and fun to use weapons than 40 unbalanced weapons, some of which are slightly tweaked versions of others.

Don’t be afraid to cut content and features. If the mod looks like it’s never going to be finished, or there’s some content that you don’t think meets the quality of the rest of the mod, then start cutting. During the development of HL at least 30% of the original features in the design were cut because it became obvious they were unattainable in our timeline, or because we decided they weren’t worth their development time. As we said above, “Quality over Quantity.” Players would prefer having 3 really good, well play-tested maps over 10 untested ones, and it’ll give your mod a reputation for quality content. Don’t let the world see your worst stuff.

Understand the engine

You really should read the documentation included in the SDK. The thing you’ll learn most by doing so isn’t whether you can do X with the engine, but rather how X should be done so it works well. You can make a gun that fires 50 rockets, but if you don’t understand the way the engine works, you might do it in a way that significantly increases the network traffic your mod uses. This is important for everyone in your mod. If your mapmakers don’t understand the engine, they’ll make huge maps without any thought for how much network data will be sent to the players in them, and everyone will blame your code for being too network intensive. If you’re a programmer, it’s a good idea to join to HL Coders mailing list, where you’ll be able to talk to many other mod programmers, and a few Valve employees as well. The mailing list has archives going back a long way, which contain a lot of useful solutions to common mod problems.

Finishing

We see a lot of mods that start out strong, produce a lot of great looking content, and never quite make the last step of getting it into the player’s hands. This section will help you get into a release mode where you’re driving towards producing a releasable version of your mod.

We chose five weeks as a starting estimate of the time it’ll take to get from normal development mode to a shippable version. It’s likely you’ll get better, and hence faster, at this with successive releases. If your mod is larger in scope, or your team is substantially international, then it is likely to take more than five weeks, though the steps will be similar to the following.. If possible, try and get the team to commit a few hours of every day to the mod for this period of time. If some team members can’t do that, you’re probably better off removing them from the shipping process. Get them to hand their part to someone else on the team who can put in the required effort. Shipping a product, even a small product, is hard and requires a substantial commitment.

There are many things in this section that might sound harsh or rigid. This is unfortunate, but a reflection on how hard a process this is. The advice here is a summation of lessons learned in the shipping of many products, and most of it a result of painful mistakes that set back our release dates. When you wonder whether a particular piece of advice here is necessary, it’s possible that we once added weeks to our release date because we didn’t take it.

This is also something that prospective employers are extremely interested in. It’s one thing to see that a mod maker has produced a bunch of cool stuff, it’s another thing entirely to see that they produced some cool stuff and actually shipped it out and people played it. The coolest map/model/code/sound/etc. in the world is useless if you couldn’t go the last mile and ship it.

Fear not, this gets a lot easier once you’ve been through it a couple of times. By the third or fourth release of your mod, you’ll be an expert!

Five weeks out

Centralize ownership

You should designate a single member of your mod team as the Shipping Leader (SL). This person will drive progress on the mod for the next five weeks. All changes made to the mod from now on should occur only at the request of the SL, and all requests for changes should be funneled through this person. No team member should make any changes, no matter how minor, to the mod unless the SL has requested that they make a particular change. This doesn’t mean the rest of the team are losing control of the mod; the SL is still a part of the team, and will be listening to all feedback. The point of the SL is to ensure that all changes to the mod are going through a single person. This avoids problems such as a mapmaker breaking the game by making a last minute change because he didn’t realize something else had changed in the game code. The SL will know the state of every component in the game (code, maps, models, textures, etc) at all times throughout the next 5 weeks to ensure this never happens.

Choosing the SL isn’t easy. Here are a few tips:

• Don’t immediately assume the person who’s currently running the mod is the best choice for SL, especially if the mod has been worked on for months and hasn’t got any closer to being released.
• Game Coders are probably the best choice. As the shipping process comes to an end, most fixes will be made in the game code.
• The SL should be highly motivated, disciplined, organized, and as ego-less as possible. The SL will need to be able to commit five weeks of his or her life to this process.
• The SL should be able to make global decisions for the mod. The SL should understand that this often requires cutting features and content in order to ship

Establish a build process

You need to create a process by which you build your mod. Building is the process of taking all your work and producing an installable, working version of the mod (generally in the form of an install file). This should be done exclusively by the SL for the next five weeks, and the SL should have a strict process that is always followed. Creating a strict process for this will ensure you don’t waste hours tracking down bugs that are simply a result of someone building in a different way than the previous person.

The SL should maintain the final/release candidate version of the mod from now on. All changes should be sent to him, and he should incorporate them into his copy of the mod one by one and with a full understanding of the impact of the changes on all parts of the mod. Don’t forget to backup your code and content regularly!

The SL should build the mod every day for playtests. More on that later.

Feature locking

Shipping is the process of locking down portions of your mod. “Locked” means that the portion is not to be touched from then on. Bugs found in locked portions of your mod should be thought about carefully. Unless the bug is really important (showstopper), just note it down and fix it in the next update of your mod. Regardless of the temptation to make that one “easy fix”, unlocking portions of your mod should be avoided as much as possible.

At this point in the shipping process, five weeks out, you should also be feature locked. This means you shouldn’t be adding any new features to your mod whatsoever. If part of your team is not involved in shipping but wants to continue working on developing the mod, they should be working in a separate content and code database. Most source code control packages allow for branching of code in this fashion. (Yes, we strongly recommend that you use some form of source control ). Every change made to the mod from now on should be a bug fix. The SL should ensure this. Even if a coder thinks of another cool feature that they say will only take them 10 minutes to code, do not let them add it in. Even if the coder sends the code, finished and bug-free, to the SL, do not add it to the mod. Save it for the next version.

A healthy attitude for the SL to have is that every change to the mod from now on will add two days to the release date.

Playtesting

From now on, you should be running playtests every day, or every second day if that’s too much. Playtests should be based on installable versions of the game, built by the SL. Don’t let team members play from their personal versions of the game. Everyone should be running a version of the mod installed from a build sent out by the SL (that’s what your viewing public will be installing and using, that’s what you should be testing). You’ll waste many hours on finding bugs caused by incompatible versions if you don’t do this.

To make this easier, the mod must be kept in a playable state at all times. Get very, very worried for every day the mod isn’t playable. If a coder or mapmaker makes a change that breaks the mod, think about it carefully before incorporating it into the SL’s build. How long will the game remain unplayable? How many playtests will you miss? How many team members won’t be able to work because the mod isn’t running? Not breaking the mod should be religion for the team.

When you do playtest, make sure as many of your team members are playing as possible. Everyone working on the game should be playing it regularly. Make sure you have some external players as well. Turn on server console logging (set “log” to “on” in the server.cfg file). This will dump all the output of the server into a file in the gamedir/logs directory ( the name of the file will match the date). Whenever any player in the game spots a bug, have them use their “say” key to say “BUG: description of bug”. Then, when the game is over, you can open up the log file and get all the bugs out of it by searching for the word “BUG.”

Bugs and changes

The SL should maintain a complete list of all bugs and changes, and their current status. Preferably this should be done using some kind of true database. E-mail is totally insufficient for tracking bugs; it’s just too easy for items to drop of the first page of a user’s mailbox, etc. After each playtest, the bugs and necessary changes from the log file should be added to the list by the SL, and assigned to team members. When a team member has fixed a bug or change, they should submit the new content to the SL, who should verify that it is fixed and then update the status on the bug list.

The bug list is a fantastic tool to evaluate how well you are progressing. It can be used to find out who is overloaded with work, who is underloaded, who is not fixing his bugs, which area of your mod is farthest from completion, and so on. Don’t remove anything from the bug list, even when it has been fixed (though you should mark it as fixed in some way, of course). It’s very useful to see what bugs have been fixed throughout the history of the project. Something might regress, re-creating a bug, and knowing who fixed it last time makes it easy to ask them what caused it. At the end of the project, you should be able to see every bug fixed and every change made in your mod for the entire shipping process. The SL shouldn’t allow any bug fix or change into the SL’s master copy of the game unless the bug/change has been detailed in the bug list.

There is software that will help you create and maintain a bug list. Alternatively, a spreadsheet will work just fine. Again, e-mail is a bad choice.

Cut or defer broken features

The hardest, nastiest, and unfortunately most necessary part of shipping is the act of being realistic and cutting features. We have a saying at Valve that everyone will have their favorite feature cut from the game. While it’s not true, it does help everyone prepare themselves for the fact that they will have features they like — or that they spent some to a lot of time on– cut. Your game simply cannot have every cool feature and still ship in a reasonable time frame. The SL should make decisions about what to finish and what to cut, based on how far along in the release process you are.

The closer you get to releasing, the more you should think about each bug as you find it. Is the bug in a feature that absolutely must be in this version? How many days will it take to fix this feature? Can this feature be cut, or deferred to a later version?

Work smart, not hard

As we’ve said over and over again, the shipping process is hard, and it’s even harder if you don’t think carefully about what to work on. Working a lot is no substitute for carefully choosing what to fix, what to defer, and what to cut out altogether. The SL should be extremely careful about which bugs/changes should be worked on, and by whom. Don’t spend a week fixing a minor problem in a feature just because the feature is cool. Fix crash bugs (showstoppers). Fix bugs that utterly prevent you from shipping the game. Fix bugs that are preventing other team members from fixing their bugs. The SL should develop categories for bugs to aid in making the right decisions. A good level of granularity is Must Fix, Severe, Medium, Minor, Zero, Deferred.

As the project gets closer to shipping, the SL should be carefully evaluating every bug that shows up. Remember, every bug that’s fixed creates more playtesting, and usually more bugs. If you are two weeks from your release date, and you’ve got a bug that will take someone three days and 500 lines of code to fix, you’re not going to make that release date unless you cut or defer that portion of the game.

Three weeks out

Content Locked

By now you should aim to be content complete. This means that all content in the game is in a locked state, except for the game code itself. All the maps, models, textures, sounds, HUD art, launcher art, and so on should be finished and in the SL’s master copy.

Shutting down

This was mentioned at the five week mark, but it’s even more important now. The SL is the only person who should be touching the master copy of the game, and he should simply be rolling in the bug fixes from the coders, who should be fixing only the bugs the SL hands them.

Playtesting

The mod should be being playtested every day, for at least two hours. Between now and when you ship, you want as many people as possible hammering away at your mod. It’s too late now to make any major game design changes – don’t even be tempted.

One week out

No last minute changes

The SL should be evaluating every change that has to be made, and deciding whether they should be deferred to the next version. Again, a healthy way to think about it is that every single change, even if it’s a single line of code, will add two days to the release date.

Two day safe period

Once every bug that is going to be fixed has been fixed, and everything else has been deferred, you’re not done. Now you wait at least 48 hours, during which time you should playtest like crazy. Try to get everyone hammering away at the game for as much time as possible. If you find any more bugs that have to be fixed, fix them, and start the 48 hours again.

If your mod passes 48 hours of heavy playtesting without finding any new issues, you’re ready to release!

Post-release

So you’ve released, the players love it, and web pages everywhere are talking about how much fun your mod is. Whether you’re done now is up to you. From our experiences in the on-line multiplayer field, a mod only stays popular as long as it’s supported. No matter how great your mod is, it’s not going to garner really significant player numbers with its first version. Player numbers are grown over time through repeated releases of new content, bug fixes, and of course, community support. Both Counter-Strike and Team Fortress started out small and grew over time. Each time they released a new version, more players tried them out and started playing them.

Knowing what to fix, what to change, and how to listen to your community is a continual learning process.

Good luck!

Related Posts

• [转]软件公司是怎么死掉的
• Tutorial of kissXML(iPhone)
• Things I’ve done int past 5 months
• WebView 小技巧

而据正统史料《中网。侏罗》记载，开饭日并非起源于中网白垩纪，而是侏罗纪。来因是由于霸王龙说他们的地盘对所有游龙开放，天真的谷龙信以为真，结伴游至鸡妹儿景点时，被蹲点已久时的霸王龙突然禽出，小龙们几乎全部入了龙口。而生还的谷龙回去哭鼻子说， “kaifang 是假的，至少是没有g的”，也就是kaifan。史称开饭 。

－－inspired by the word “开饭日”

转自阿杰的QQ空间,一位特立独行的程序员.

3月23日,阴有多雨,上海.

有一天,小明问,google是什么?

Related Posts

• Apple 发疯了
• Tutorial of kissXML(iPhone)
• PlutoCMS! 基于ROR的内容管理系统

而在配置文件中没有对IPV6做白名单操作。

#                   PostgreSQL HOST ACCESS CONTROL FILE
#

local  all                                          trust
host   all        127.0.0.1      255.255.255.255    trust
host   booktown   192.168.1.3    255.255.255.255    ident    sales
host   all        192.168.1.4    255.255.255.255    ident    audit
当然最简单的做法，只要在网络连接中将 ipv6 关闭就能连接了。

Related Posts

• 小试Unity游戏引擎
• What is iPad All About?
• [烂]ccav再次糟蹋好东西
• now or never

同事版本 1.0.0.104
我的版本 1.0.0.105

It’s a Fake version.
长见识了,不只是魔兽世界,到处都是和谐.

刚好今天在rss看到一篇分享过来的文章

中文版GTalk是没有加密的

http://it.solidot.org/article.pl?sid=09/08/26/0621250&from=rss

真有趣

Related Posts

• [Rails]DoiTeam 基于团队的任务管理系统
• A new approach to my career
• 2009-2010
• OSX Terminal(终端) 使用快捷键

With iPad devices, you now have an opportunity to create Multi-Touch applications on a larger display than previously available. The 1024 x 768 pixel screen provides much more room to display content, or provide greater detail for your existing content. And the addition of new interface elements in iPhone OS 3.2 enable an entirely new breed of applications.

The size and capabilities of iPad mean that it is now possible to create desktop-class applications for a portable device. The increased screen size gives you the space you need to present almost any kind of content. The Multi-Touch interface and support for physical keyboards enables diverse modes of interaction, ranging from simple gesture-drive interaction to content creation and substantial text input.

The increased screen size also makes it possible to create a new class of immersive applications that replicate real-world objects in a digital form. For example, the Contacts and Calendar applications on iPad look more like the paper-based address book and calendar you might have on your desk at home. These digital metaphors for real-life objects provide a more natural and familiar experience for the user and can make your applications more compelling to use. But because they are digital, you can go beyond the limitations of the physical objects themselves and create applications that enable greater productivity and convenience.

对于iPad,还是觉得得写点什么.
这是开发文档中对iPad的定义,同志们,要领会党的精神呀!
太晚了.明天继续.

Related Posts

• now or never
• Things I’ve done int past 5 months
• [转]软件公司是怎么死掉的
• iBook Page Curl Animation 翻页效果

最近很火的李献计历险记:

是作者(年轻优秀的飞行员)一个人2年多的作品,钦佩.
专注+不放弃+低调

Related Posts

• 12月串烧-年轻人就要飘逸
• 锅也是个杯具
• 五月天
• Fun Theory

首先勾选设置-》键盘-》使用 option 键作为 meta 键。

然后就可以使用如下快捷键了：

• control + a / e    回到命令行头/尾
• option + b / f     向前/后跳一个单词
• control +u /k    删除光标前/后 所有单词
• control + y       撤销上个操作

Enjoy It !

最后有个好玩的命令，查看最常用的10个命令（最近500个命令）

awk ‘{print $1}’ ~/.bash_history | sort | uniq -c | sort -gr | head

我的结果

100 ls
68 git
63 cd
54 svn
28 fq
20 find
18 open
18 curl
16 ssh
10 rm

终于不再全是 ls + cd 了。

Related Posts

• Fake Version
• 2009-2010
• 用 Redmine 管理iPhone项目中过多的图片文件
• iPhone 组件模板（设计用）分享

sudo cp /etc/apt/sources.list /etc/apt/sources.list_backup

编辑软件源:

sudo gedit /etc/apt/sources.list

更新软件源:

sudo apt-get update

#—– contents of sources.list  —————————————————————#

#传说中的中国科技大学 5M/s
deb http://debian.ustc.edu.cn/ubuntu/ karmic main restricted universe multiverse
deb http://debian.ustc.edu.cn/ubuntu/ karmic-backports restricted universe multiverse
deb http://debian.ustc.edu.cn/ubuntu/ karmic-proposed main restricted universe multiverse
deb http://debian.ustc.edu.cn/ubuntu/ karmic-security main restricted universe multiverse
deb http://debian.ustc.edu.cn/ubuntu/ karmic-updates main restricted universe multiverse
deb-src http://debian.ustc.edu.cn/ubuntu/ karmic main restricted universe multiverse
deb-src http://debian.ustc.edu.cn/ubuntu/ karmic-backports main restricted universe multiverse
deb-src http://debian.ustc.edu.cn/ubuntu/ karmic-proposed main restricted ukarmicniverse multiverse
deb-src http://debian.ustc.edu.cn/ubuntu/ karmic-security main restricted universe multiverse
deb-src http://debian.ustc.edu.cn/ubuntu/ karmic-updates main restricted universe multiverse
#传说中的北京交大 速度 2M/s
deb http://mirror.bjtu.edu.cn/ubuntu/ karmic main restricted universe multiverse
deb http://mirror.bjtu.edu.cn/ubuntu/ karmic-backports restricted universe multiverse
deb http://mirror.bjtu.edu.cn/ubuntu/ karmic-proposed main restricted universe multiverse
deb http://mirror.bjtu.edu.cn/ubuntu/ karmic-security main restricted universe multiverse
deb http://mirror.bjtu.edu.cn/ubuntu/ karmic-updates main restricted universe multiverse
deb-src http://mirror.bjtu.edu.cn/ubuntu/ karmic main restricted universe multiverse
deb-src http://mirror.bjtu.edu.cn/ubuntu/ karmic-backports main restricted universe multiverse
deb-src http://mirror.bjtu.edu.cn/ubuntu/ karmic-proposed main restricted universe multiverse
deb-src http://mirror.bjtu.edu.cn/ubuntu/ karmic-security main restricted universe multiverse
deb-src http://mirror.bjtu.edu.cn/ubuntu/ karmic-updates main restricted universe multiverse
#传说中的上海交通大学，最热门的源之一
deb http://ftp.sjtu.edu.cn/ubuntu/ karmic main multiverse restricted universe
deb http://ftp.sjtu.edu.cn/ubuntu/ karmic-backports main multiverse restricted universe
deb http://ftp.sjtu.edu.cn/ubuntu/ karmic-proposed main multiverse restricted universe
deb http://ftp.sjtu.edu.cn/ubuntu/ karmic-security main multiverse restricted universe
deb http://ftp.sjtu.edu.cn/ubuntu/ karmic-updates main multiverse restricted universe
deb http://ftp.sjtu.edu.cn/ubuntu-cn/ karmic main multiverse restricted universe
deb-src http://ftp.sjtu.edu.cn/ubuntu/ karmic main multiverse restricted universe
deb-src http://ftp.sjtu.edu.cn/ubuntu/ karmic-backports main multiverse restricted universe
deb-src http://ftp.sjtu.edu.cn/ubuntu/ karmic-proposed main multiverse restricted universe
deb-src http://ftp.sjtu.edu.cn/ubuntu/ karmic-security main multiverse restricted universe
deb-src http://ftp.sjtu.edu.cn/ubuntu/ karmic-updates main multiverse restricted universe
#传说中的清华大学ubuntu源 300k/s
deb ftp://ftp3.tsinghua.edu.cn/mirror/ubuntu/ubuntu/ karmic main restricted universe multiverse
deb ftp://ftp3.tsinghua.edu.cn/mirror/ubuntu/ubuntu/ karmic-backports restricted universe multiverse
deb ftp://ftp3.tsinghua.edu.cn/mirror/ubuntu/ubuntu/ karmic-proposed main restricted universe multiverse
deb ftp://ftp3.tsinghua.edu.cn/mirror/ubuntu/ubuntu/ karmic-security main restricted universe multiverse
deb ftp://ftp3.tsinghua.edu.cn/mirror/ubuntu/ubuntu/ karmic-updates main restricted universe multiverse
deb-src ftp://ftp3.tsinghua.edu.cn/mirror/ubuntu/ubuntu/ karmic main restricted universe multiverse
deb-src ftp://ftp3.tsinghua.edu.cn/mirror/ubuntu/ubuntu/ karmic-backports main restricted universe multiverse
deb-src ftp://ftp3.tsinghua.edu.cn/mirror/ubuntu/ubuntu/ karmic-proposed main restricted universe multiverse
deb-src ftp://ftp3.tsinghua.edu.cn/mirror/ubuntu/ubuntu/ karmic-security main restricted universe multiverse
deb-src ftp://ftp3.tsinghua.edu.cn/mirror/ubuntu/ubuntu/ karmic-updates main restricted universe multiverse
#传说中的兰州大学 260k/s
deb ftp://mirror.lzu.edu.cn/ubuntu/ karmic main restricted universe multiverse
deb ftp://mirror.lzu.edu.cn/ubuntu/ karmic-backports restricted universe multiverse
deb ftp://mirror.lzu.edu.cn/ubuntu/ karmic-proposed main restricted universe multiverse
deb ftp://mirror.lzu.edu.cn/ubuntu/ karmic-security main restricted universe multiverse
deb ftp://mirror.lzu.edu.cn/ubuntu/ karmic-updates main restricted universe multiverse
deb-src ftp://mirror.lzu.edu.cn/ubuntu/ karmic main restricted universe multiverse
deb-src ftp://mirror.lzu.edu.cn/ubuntu/ karmic-backports main restricted universe multiverse
deb-src ftp://mirror.lzu.edu.cn/ubuntu/ karmic-proposed main restricted universe multiverse
deb-src ftp://mirror.lzu.edu.cn/ubuntu/ karmic-security main restricted universe multiverse
deb-src ftp://mirror.lzu.edu.cn/ubuntu/ karmic-updates main restricted universe multiverse
#传说中的台湾大学 中国电信adsl 150k/s
deb http://ubuntu.csie.ntu.edu.tw/ubuntu/ karmic main restricted universe multiverse
deb http://ubuntu.csie.ntu.edu.tw/ubuntu/ karmic-backports restricted universe multiverse
deb http://ubuntu.csie.ntu.edu.tw/ubuntu/ karmic-proposed main restricted universe multiverse
deb http://ubuntu.csie.ntu.edu.tw/ubuntu/ karmic-security main restricted universe multiverse
deb http://ubuntu.csie.ntu.edu.tw/ubuntu/ karmic-updates main restricted universe multiverse
deb-src http://ubuntu.csie.ntu.edu.tw/ubuntu/ karmic main restricted universe multiverse
deb-src http://ubuntu.csie.ntu.edu.tw/ubuntu/ karmic-backports main restricted universe multiverse
deb-src http://ubuntu.csie.ntu.edu.tw/ubuntu/ karmic-proposed main restricted universe multiverse
deb-src http://ubuntu.csie.ntu.edu.tw/ubuntu/ karmic-security main restricted universe multiverse
deb-src http://ubuntu.csie.ntu.edu.tw/ubuntu/ karmic-updates main restricted universe multiverse
#传说中的电子科大
deb http://ubuntu.uestc.edu.cn/ubuntu karmic main restricted universe multiverse
deb http://ubuntu.uestc.edu.cn/ubuntu karmic-backports main restricted universe multiverse
deb http://ubuntu.uestc.edu.cn/ubuntu karmic-proposed main restricted universe multiverse
deb http://ubuntu.uestc.edu.cn/ubuntu karmic-security main restricted universe multiverse
deb http://ubuntu.uestc.edu.cn/ubuntu karmic-updates main restricted universe multiverse
deb-src http://ubuntu.uestc.edu.cn/ubuntu karmic main restricted universe multiverse
deb-src http://ubuntu.uestc.edu.cn/ubuntu karmic-backports main restricted universe multiverse
deb-src http://ubuntu.uestc.edu.cn/ubuntu karmic-proposed main restricted universe multiverse
deb-src http://ubuntu.uestc.edu.cn/ubuntu karmic-security main restricted universe multiverse
deb-src http://ubuntu.uestc.edu.cn/ubuntu karmic-updates main restricted universe multiverse
deb http://ubuntu.uestc.edu.cn/ubuntu-cn karmic main restricted universe multiverse
deb http://ubuntu.uestc.edu.cn/ubuntustudio karmic main
#传说中的清华，,但不是清华大学的官方域名
deb http://mirror9.net9.org/ubuntu/ karmic main multiverse restricted universe
deb http://mirror9.net9.org/ubuntu/ karmic-backports main multiverse restricted universe
deb http://mirror9.net9.org/ubuntu/ karmic-proposed main multiverse restricted universe
deb http://mirror9.net9.org/ubuntu/ karmic-security main multiverse restricted universe
deb http://mirror9.net9.org/ubuntu/ karmic-updates main multiverse restricted universe
deb-src http://mirror9.net9.org/ubuntu/ karmic main multiverse restricted universe
deb-src http://mirror9.net9.org/ubuntu/ karmic-backports main multiverse restricted universe
deb-src http://mirror9.net9.org/ubuntu/ karmic-proposed main multiverse restricted universe
deb-src http://mirror9.net9.org/ubuntu/ karmic-security main multiverse restricted universe
deb-src http://mirror9.net9.org/ubuntu/ karmic-updates main multiverse restricted universe
deb http://mirror9.net9.org/ubuntu-cn/ karmic main multiverse restricted universe
#传说中的电子科大,但不是uestc的官方域名
deb http://ubuntu.dormforce.net/ubuntu karmic main restricted universe multiverse
deb http://ubuntu.dormforce.net/ubuntu karmic-backports main restricted universe multiverse
deb http://ubuntu.dormforce.net/ubuntu karmic-proposed main restricted universe multiverse
deb http://ubuntu.dormforce.net/ubuntu karmic-security main restricted universe multiverse
deb http://ubuntu.dormforce.net/ubuntu karmic-updates main restricted universe multiverse
deb-src http://ubuntu.dormforce.net/ubuntu karmic main restricted universe multiverse
deb-src http://ubuntu.dormforce.net/ubuntu karmic-backports main restricted universe multiverse
deb-src http://ubuntu.dormforce.net/ubuntu karmic-proposed main restricted universe multiverse
deb-src http://ubuntu.dormforce.net/ubuntu karmic-security main restricted universe multiverse
deb-src http://ubuntu.dormforce.net/ubuntu karmic-updates main restricted universe multiverse
#传说中的东北大学更新服务器：
deb ftp://ftp.neu.edu.cn/mirror/archive.ubuntu.com/ubuntu/ karmic main multiverse restricted universe
deb ftp://ftp.neu.edu.cn/mirror/archive.ubuntu.com/ubuntu/ karmic-backports main multiverse restricted universe
deb ftp://ftp.neu.edu.cn/mirror/archive.ubuntu.com/ubuntu/ karmic-proposed main multiverse restricted universe
deb ftp://ftp.neu.edu.cn/mirror/archive.ubuntu.com/ubuntu/ karmic-security main multiverse restricted universe
deb ftp://ftp.neu.edu.cn/mirror/archive.ubuntu.com/ubuntu/ karmic-updates main multiverse restricted universe
deb-src ftp://ftp.neu.edu.cn/mirror/archive.ubuntu.com/ubuntu/ karmic main multiverse restricted universe
deb-src ftp://ftp.neu.edu.cn/mirror/archive.ubuntu.com/ubuntu/ karmic-backports main multiverse restricted universe
deb-src ftp://ftp.neu.edu.cn/mirror/archive.ubuntu.com/ubuntu/ karmic-proposed main multiverse restricted universe
deb-src ftp://ftp.neu.edu.cn/mirror/archive.ubuntu.com/ubuntu/ karmic-security main multiverse restricted universe
deb-src ftp://ftp.neu.edu.cn/mirror/archive.ubuntu.com/ubuntu/ karmic-updates main multiverse restricted universe
#传说中的厦门大学
deb ftp://ubuntu.realss.cn/ubuntu/ karmic main restricted universe multiverse
deb ftp://ubuntu.realss.cn/ubuntu/ karmic-backports restricted universe multiverse
deb ftp://ubuntu.realss.cn/ubuntu/ karmic-proposed main restricted universe multiverse
deb ftp://ubuntu.realss.cn/ubuntu/ karmic-security main restricted universe multiverse
deb ftp://ubuntu.realss.cn/ubuntu/ karmic-updates main restricted universe multiverse
deb-src ftp://ubuntu.realss.cn/ubuntu/ karmic main restricted universe multiverse
deb-src ftp://ubuntu.realss.cn/ubuntu/ karmic-backports main restricted universe multiverse
deb-src ftp://ubuntu.realss.cn/ubuntu/ karmic-proposed main restricted universe multiverse
deb-src ftp://ubuntu.realss.cn/ubuntu/ karmic-security main restricted universe multiverse
deb-src ftp://ubuntu.realss.cn/ubuntu/ karmic-updates main restricted universe multiverse
#传说中的西南财经大学
deb http://ftp.swufe.edu.cn/mirror/ubuntu/ karmic main restricted universe multiverse
deb http://ftp.swufe.edu.cn/mirror/ubuntu/ karmic-backports restricted universe multiverse
deb http://ftp.swufe.edu.cn/mirror/ubuntu/ karmic-proposed main restricted universe multiverse
deb http://ftp.swufe.edu.cn/mirror/ubuntu/ karmic-security main restricted universe multiverse
deb http://ftp.swufe.edu.cn/mirror/ubuntu/ karmic-updates main restricted universe multiverse
deb-src http://ftp.swufe.edu.cn/mirror/ubuntu/ karmic main restricted universe multiverse
deb-src http://ftp.swufe.edu.cn/mirror/ubuntu/ karmic-backports main restricted universe multiverse
deb-src http://ftp.swufe.edu.cn/mirror/ubuntu/ karmic-proposed main restricted universe multiverse
deb-src http://ftp.swufe.edu.cn/mirror/ubuntu/ karmic-security main restricted universe multiverse
deb-src http://ftp.swufe.edu.cn/mirror/ubuntu/ karmic-updates main restricted universe multiverse

Related Posts

• Downloads
• now or never
• A new approach to my career
• Tutorial of kissXML(iPhone)