mirror of
https://gh-proxy.org/https://github.com/klinsmaya/dashjim.github.com.git
synced 2026-11-08 01:16:54 +08:00
added a favicon.ico and added two new blogs
This commit is contained in:
Jim
@@ -38,16 +38,16 @@ tags:
|
||||
本书具有一定的官方性质，是正式出版物的免费版，学习Git的屠龙刀。其深入浅出，长度适中，讲解精练到位，结构合理，通读此书是提升功力的捷径。
|
||||
|
||||
### [图解Git](http://marklodato.github.io/visual-git-guide/index-zh-cn.html)
|
||||
真是一图胜千言，在众多文档中此文可以算是出奇制胜，其它文档中较难理解的东西到了这里迎刃而解，称之为倚天剑毫不过分。倚天配屠龙 - 可在读Pro Git时配套用。
|
||||
真是一图胜千言，在众多文档中此文可以算是出奇制胜，其它文档中较难理解的东西到了这里迎刃而解，称之为倚天剑毫不过分。倚天配屠龙 - 可在读'Pro Git'时配套用。
|
||||
|
||||
### [Git Magic](http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/zh_cn/ch02.html)
|
||||
斯坦福血统，内容覆盖广，但解释偏少，可在读完Pro Git之后用来开拓思路。
|
||||
斯坦福血统，内容覆盖广，但解释偏少，可在读完'Pro Git'之后用来开拓思路。
|
||||
|
||||
### [Git Community Book 中文版](http://gitbook.liuhui998.com/index.html)
|
||||
因为程度上本书和Pro Git冲突，本人没有读过此书，但仅看其完整的体系结构和中文翻译是值得推荐的。
|
||||
因为程度上本书和'Pro Git'冲突，本人没有读过此书，但仅看其完整的体系结构和中文翻译是值得推荐的。
|
||||
|
||||
### [Git分支管理策略](http://www.ruanyifeng.com/blog/2012/07/git.html)
|
||||
如题
|
||||
了解branch指令是一回事，怎么管理这些branch又是另一回事。'Pro Git'有分支管理的章节，不过没有这里说的详细。
|
||||
|
||||
### GitHub相关
|
||||
相信不少人在学习GIT的过程中都有在Github上建blog的冲动，下面是一些对Github不错的介绍。搭建Blog本身也是一个GIT学习和使用的过程。
|
||||
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
layout: post
|
||||
title: 如何在Linux下实现QoS
|
||||
categories:
|
||||
- Technology
|
||||
tags:
|
||||
- Telephone
|
||||
---
|
||||
|
||||
QoS本身是一个比较大的话题，但是毫无疑问，对于音频，视频应用来说QoS的作用是巨大的。有工程师跟我说过在实施时加不加QoS有很大的差别。这里特别提醒一下QoS要在网络的所有结点上启用才能发挥最大效果（结点包括，路由器，服务器等），最起码也要保证加在比较繁忙的结点上，不然没有多大意义。
|
||||
下面是在Linux服务器上给相关端口加上高优先级的脚本。大家可以举一反三给特定的IP包加上优先级。
|
||||
|
||||
```
|
||||
|
||||
LOGFILE=/tmp/logs/iptables.log
|
||||
SERVICE=`which service`
|
||||
IPTABLES_STATUS=`$SERVICE iptables status 2> /dev/null | head -n 1`
|
||||
if [ `rpm -qa iptables|grep -c iptables` -eq 0 -o -z "$IPTABLES_STATUS" ]; then
|
||||
echo `date +"%F %T"` " - IPTABLES NOT INSTALLED!! QoS NOT SET!!\n" >> $LOGFILE
|
||||
exit 1
|
||||
fi
|
||||
if [ `echo "$IPTABLES_STATUS" | grep -c stopped` -gt 0 ]; then
|
||||
echo `date +"%F %T"` " - IPTABLES is stopped and will be started!\n" >> $LOGFILE
|
||||
fi
|
||||
|
||||
IPTABLES="$(which iptables)"
|
||||
|
||||
# RESET DEFAULT POLICIES
|
||||
$IPTABLES -P INPUT ACCEPT
|
||||
$IPTABLES -P FORWARD ACCEPT
|
||||
$IPTABLES -P OUTPUT ACCEPT
|
||||
$IPTABLES -t nat -P PREROUTING ACCEPT
|
||||
$IPTABLES -t nat -P POSTROUTING ACCEPT
|
||||
$IPTABLES -t nat -P OUTPUT ACCEPT
|
||||
$IPTABLES -t mangle -P PREROUTING ACCEPT
|
||||
$IPTABLES -t mangle -P OUTPUT ACCEPT
|
||||
|
||||
# FLUSH ALL RULES, ERASE NON-DEFAULT CHAINS
|
||||
$IPTABLES -F
|
||||
$IPTABLES -X
|
||||
$IPTABLES -t nat -F
|
||||
$IPTABLES -t nat -X
|
||||
$IPTABLES -t mangle -F
|
||||
$IPTABLES -t mangle -X
|
||||
|
||||
# ADD QoS RULES
|
||||
$IPTABLES -t mangle -A OUTPUT -p tcp --sport 1935 -j DSCP --set-dscp 0x22
|
||||
$IPTABLES -t mangle -A OUTPUT -p tcp --sport 443 -j DSCP --set-dscp 0x22
|
||||
$IPTABLES -t mangle -A OUTPUT -p tcp --sport 5060 -j DSCP --set-dscp 0x22
|
||||
$IPTABLES -t mangle -A OUTPUT -p tcp --sport 5061 -j DSCP --set-dscp 0x22
|
||||
$IPTABLES -t mangle -A OUTPUT -p tcp --dport 5060 -j DSCP --set-dscp 0x22
|
||||
$IPTABLES -t mangle -A OUTPUT -p tcp --dport 5061 -j DSCP --set-dscp 0x22
|
||||
|
||||
echo "******" `date +"%F %T"` "******" >> $LOGFILE
|
||||
$SERVICE iptables save >> $LOGFILE
|
||||
echo "$IPTABLES -t mangle -L" >> $LOGFILE
|
||||
```
|
||||
其原理非常简单，就是给所有通过某端口的包加上(`mangle`)特定标志(`dscp 0x22`)，这样相关的。脚本中的`dscp 0x22`是针对Avaya和北电的产品的，不同厂商的产品可能使用不同的数字，请参考单独的页面介绍[Notes on QOS for videoconferencing](http://andrew.triumf.ca/vidconf_QOS.html)。加完后你的`ipdables`看起来应该是这个样子。然后你的包就会优先被处理了。
|
||||
|
||||
```
|
||||
Chain POSTROUTING (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
************************************
|
||||
****** 2013-11-27 16:06:20 ******
|
||||
iptables: Saving firewall rules to /etc/sysconfig/iptables: ESC[60G[ESC[0;32m OK ESC[0;39m]
|
||||
/sbin/iptables -t mangle -L
|
||||
Chain PREROUTING (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
|
||||
Chain INPUT (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
|
||||
Chain FORWARD (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
|
||||
Chain OUTPUT (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
DSCP tcp -- anywhere anywhere tcp spt:macromedia-fcs DSCP set 0x22
|
||||
DSCP tcp -- anywhere anywhere tcp spt:https DSCP set 0x22
|
||||
DSCP tcp -- anywhere anywhere tcp spt:sip DSCP set 0x22
|
||||
DSCP tcp -- anywhere anywhere tcp spt:sip-tls DSCP set 0x22
|
||||
DSCP tcp -- anywhere anywhere tcp dpt:sip DSCP set 0x22
|
||||
DSCP tcp -- anywhere anywhere tcp dpt:sip-tls DSCP set 0x22
|
||||
|
||||
Chain POSTROUTING (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
```
|
||||
@@ -0,0 +1,176 @@
|
||||
---
|
||||
layout: post
|
||||
title: 发明人Linus Torvalds给出的Git使用建议
|
||||
categories:
|
||||
- Technology
|
||||
tags:
|
||||
- Git
|
||||
---
|
||||
|
||||
##引言
|
||||
如何更好的使用Git？作为Git的发明人Torvalds会给出什么样的建议呢？
|
||||
[Linus Torvalds的博客］(http://torvalds-family.blogspot.sg/)和他的Mail list里提到过使用Git的一些注意事项。
|
||||
|
||||
现在开始挖坟啦！话说2009年的某一天Linux 2.6.31内核的分枝合并工作进行的很顺利（你知道现在Linux内核的版本号吗？），Torvalds的心情大好写下一篇与Git有一点点关系的[blog](http://torvalds-family.blogspot.sg/2009/06/happiness-is-warm-scm.html)，然后后面有两个人在回复里问Git应该怎么用呢？
|
||||
|
||||
###问题
|
||||
>As a Git n00b, would be nice to see a post on what these "rules that work" are.
|
||||
|
||||
Linus Torvalds刚好心情大好就给整理了一下。
|
||||
|
||||
###Linus回答
|
||||
|
||||
It's basically a matter of finding the right balance on a couple of different axises:
|
||||
|
||||
"clean history":
|
||||
|
||||
Balancing the need to clean up after mistakes (aka "rewriting history") using tools like 'git rebase', but then not doing it so much that you actually rewrite other peoples commits or lose all sight of the important history (like the fact that you tested one particular test, and if you then rewrite the history, all your testing is now dubious).
|
||||
|
||||
"Merging too much vs too little":
|
||||
|
||||
Merging is nice, because if you have concurrent development, a merge will tie the two branches together and allows you to test and develop on top of both changes.
|
||||
|
||||
But the downside is that merging too eagerly means that two separate branches that are for two different features are now tied together, and you can never separate the two (at least without re-doing the whole history).
|
||||
|
||||
So merging too much results in a very messy history, where you can't see what the actual different "topics" were. And it results in a tree where upstream (that is - me) can't review and pull the features one by one.
|
||||
|
||||
There's a few rants and rules about this that I did on the mailing lists last merge window. See for example [rant](http://www.mail-archive.com/[email protected]/msg39091.html)
|
||||
|
||||
###另一个Mail List里的意见
|
||||
我也给复制过来了，这样更完整一点。
|
||||
|
||||
###邮件上下文
|
||||
> My plans from now on are just to send you non-linear trees, whenever I
|
||||
> merge a patch into my next tree thats when it stays in there, I'll pull
|
||||
> Eric's tree directly into my tree and then I'll send the results, I
|
||||
> thought we cared about a clean merge history but as I said without some
|
||||
> document in the kernel tree I've up until now had no real idea what you
|
||||
> wanted.
|
||||
|
||||
###Linus回答
|
||||
> 注意Linus的原文就是用Markdown格式写的，下面是原文，我没有加入任何Markdown格式。说明Linus在写邮件的时候是极为注意细节的。大家可以去查看[原文的Raw格式](http://www.mail-archive.com/[email protected]/msg39091.html)
|
||||
I want clean history, but that really means (a) clean and (b) history.
|
||||
|
||||
People can (and probably should) rebase their _private_ trees (their own
|
||||
work). That's a _cleanup_. But never other peoples code. That's a "destroy
|
||||
history"
|
||||
|
||||
So the history part is fairly easy. There's only one major rule, and one
|
||||
minor clarification:
|
||||
|
||||
- You must never EVER destroy other peoples history. You must not rebase
|
||||
commits other people did. Basically, if it doesn't have your sign-off
|
||||
on it, it's off limits: you can't rebase it, because it's not yours.
|
||||
|
||||
Notice that this really is about other peoples _history_, not about
|
||||
other peoples _code_. If they sent stuff to you as an emailed patch,
|
||||
and you applied it with "git am -s", then it's their code, but it's
|
||||
_your_ history.
|
||||
|
||||
So you can go wild on the "git rebase" thing on it, even though you
|
||||
didn't write the code, as long as the commit itself is your private
|
||||
one.
|
||||
|
||||
- Minor clarification to the rule: once you've published your history in
|
||||
some public site, other people may be using it, and so now it's clearly
|
||||
not your _private_ history any more.
|
||||
|
||||
So the minor clarification really is that it's not just about "your
|
||||
commit", it's also about it being private to your tree, and you haven't
|
||||
pushed it out and announced it yet.
|
||||
|
||||
That's fairly straightforward, no?
|
||||
|
||||
Now the "clean" part is a bit more subtle, although the first rules are
|
||||
pretty obvious and easy:
|
||||
|
||||
- Keep your own history readable
|
||||
|
||||
Some people do this by just working things out in their head first, and
|
||||
not making mistakes. but that's very rare, and for the rest of us, we
|
||||
use "git rebase" etc while we work on our problems.
|
||||
|
||||
So "git rebase" is not wrong. But it's right only if it's YOUR VERY OWN
|
||||
PRIVATE git tree.
|
||||
|
||||
- Don't expose your crap.
|
||||
|
||||
This means: if you're still in the "git rebase" phase, you don't push
|
||||
it out. If it's not ready, you send patches around, or use private git
|
||||
trees (just as a "patch series replacement") that you don't tell the
|
||||
public at large about.
|
||||
|
||||
It may also be worth noting that excessive "git rebase" will not make
|
||||
things any cleaner: if you do too many rebases, it will just mean that all
|
||||
your old pre-rebase testing is now of dubious value. So by all means
|
||||
rebase your own work, but use _some_ judgement in it.
|
||||
|
||||
NOTE! The combination of the above rules ("clean your own stuff" vs "don't
|
||||
clean other peoples stuff") have a secondary indirect effect. And this is
|
||||
where it starts getting subtle: since you most not rebase other peoples
|
||||
work, that means that you must never pull into a branch that isn't already
|
||||
in good shape. Because after you've done a merge, you can no longer rebase
|
||||
you commits.
|
||||
|
||||
Notice? Doing a "git pull" ends up being a synchronization point. But it's
|
||||
all pretty easy, if you follow these two rules about pulling:
|
||||
|
||||
- Don't merge upstream code at random points.
|
||||
|
||||
You should _never_ pull my tree at random points (this was my biggest
|
||||
issue with early git users - many developers would just pull my current
|
||||
random tree-of-the-day into their development trees). It makes your
|
||||
tree just a random mess of random development. Don't do it!
|
||||
|
||||
And, in fact, preferably you don't pull my tree at ALL, since nothing
|
||||
in my tree should be relevant to the development work _you_ do.
|
||||
Sometimes you have to (in order to solve some particularly nasty
|
||||
dependency issue), but it should be a very rare and special thing, and
|
||||
you should think very hard about it.
|
||||
|
||||
But if you want to sync up with major releases, do a
|
||||
|
||||
git pull linus-repo v2.6.29
|
||||
|
||||
or similar to synchronize with that kind of _non_random_ point. That
|
||||
all makes sense. A "Merge v2.6.29 into devel branch" makes complete
|
||||
sense as a merge message, no? That's not a problem.
|
||||
|
||||
But if I see a lot of "Merge branch 'linus'" in your logs, I'm not
|
||||
going to pull from you, because your tree has obviously had random crap
|
||||
in it that shouldn't be there. You also lose a lot of testability,
|
||||
since now all your tests are going to be about all my random code.
|
||||
|
||||
- Don't merge _downstream_ code at random points either.
|
||||
|
||||
Here the "random points" comment is a dual thing. You should not mege
|
||||
random points as far as downstream is concerned (they should tell you
|
||||
what to merge, and why), but also not random points as far as your tree
|
||||
is concerned.
|
||||
|
||||
Simple version: "Don't merge unrelated downstream stuff into your own
|
||||
topic branches."
|
||||
|
||||
Slightly more complex version: "Always have a _reason_ for merging
|
||||
downstream stuff". That reason might be: "This branch is the release
|
||||
branch, and is _not_ the 'random development' branch, and I want to
|
||||
merge that ready feature into my release branch because it's going to
|
||||
be part of my next release".
|
||||
|
||||
See? All the rules really are pretty simple. There's that somewhat subtle
|
||||
interaction between "keep your own history clean" and "never try to clean
|
||||
up _other_ proples histories", but if you follow the rules for pulling,
|
||||
you'll never have that problem.
|
||||
|
||||
Of course, in order for all this to work, you also have to make sure that
|
||||
the people you pull _from_ also have clean histories.
|
||||
|
||||
And how do you make sure of that? Complain to them if they don't. Tell
|
||||
them what they should do, and what they do wrong. Push my complaints down
|
||||
to the people you pull from. You're very much allowed to quote me on this
|
||||
and use it as an explanation of "do this, because that is what Linus
|
||||
expects from the end result".
|
||||
|
||||
Linus
|
||||
|
||||
> 附本文相关文章--[Git-学习路线图及中文资料推荐](http://blog.sevenche.com/2014/02/Git-%E5%AD%A6%E4%B9%A0%E8%B7%AF%E7%BA%BF%E5%9B%BE%E5%8F%8A%E4%B8%AD%E6%96%87%E8%B5%84%E6%96%99%E6%8E%A8%E8%8D%90/)
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Reference in New Issue
Block a user