V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  msg7086  ›  全部回复第 1 页 / 共 1023 页
回复总数  20459
1  2  3  4  5  6  7  8  9  10 ... 1023  
1 天前
回复了 casey8802 创建的主题 生活 婚后一周最少见几次?
交往的时候一周也就见一次。
咱先从基础的开始。

这里先讨论有线回程 Mesh 。

WiFi Mesh 应该是属于 OSI 2 层(数据链路层)的东西。最下面的物理层当然就是无线网卡和电波了,物理层上面就是 WiFi 协议。Mesh 这些也都是在 WiFi 协议上做的。
你说的家用路由器设备,其实是在说网关+交换机设备。交换机确实是 2 层的没问题,但网关 NAT 是 3 层设备,会做 IP 转译。
正常我们家用的 Mesh 是一个 2 层 Mesh ,也就是在同一个网关内部用不同设备来实现。
那么基于这个前提就很好理解了,你需要一个网关( 3 层),任意个交换机( 2 层),和任意个无线( 2 层)。

一个网关,上面做一个 DHCP 服务,为所有设备分配 IP 地址,比如说 192.168.1.x/24 。
任意个交换机,4+1 口路由器上的 4 口就是一个交换机。
任意个无线。你有多个品牌的无线路由器,你可以把他们切到 AP 模式(或者关闭 DHCP 后从 LAN 口接上联),他们就成了傻瓜无线设备。再把他们的无线设置都改成完全一样就行了。

这样就组成了一个最基础的有线 Mesh 。

如果要实现无缝漫游,那还需要支持 802.11k/v/r 协议的一种或多种,并且把他们都配置好。

再然后如果要做无线 Mesh ,还需要设备固件能支持互相互联,这个虽然有公共标准但是好像没有很普及?各个品牌自己的无线 Mesh 应该都是私有协议吧。这块我不熟,可能不对。

总之 IP 地址是和 DHCP 有关,和 Mesh 本身是没关系的。而且 Mesh 是要求同网段才行,否则漫游完就断网了。
看你说阵列柜我还以为你要上超微 847 之类的呢……
null 一般指的是值缺失。None 是值存在但语义为空。
钱只会从一个人手里转到另一个人手里。
就看你是钱转入的那只手还是钱转出的那只手了。
正常的股市(不谈 A 股那些),上市企业用你的钱去发展,钱生钱,然后给股东分红,稳定获利。
区块链市场,如果这个链没办法从链外获得价值,那最终就会变成零和游戏,别人年化 30%就是从你账户上化出去的。
OLED 都会烧,亮度高,时间长,画面固定,最后一定会烧的。很多人手机买来高强度刷抖音什么的,很快右侧就会出现各种按钮的烧瓶残留。
不如直接买一加原生秒解 BL 。就算以后国内的一加禁止了,也可以买国际版。
内核包含大多数开源驱动。如果要用闭源驱动或者比较少见的设备的驱动需要自己安装。
Windows 系统内其实也包含了大多数设备的驱动,自己安装驱动主要是为了拿到最新版。
靠谱盘基本都是大容量企业级。就算对容量没需求也可以考虑买大硬盘。
就跟,开汽车了会不会降低驾驭马车的能力一样。
用高级语言一样会降低你写 C 和汇编的能力的。
17 天前
回复了 hanxu317138 创建的主题 git git rebase 那么重要么???
(续)
总之 git 本身也不是一本史书,git 是一个 Source code management ,这个软件的核心目的是管理源代码,最终这个管理是要为软件开发和发布服务的,对软件开发和软件发布有益的做法就是正确的做法,如果一种做法导致软件开发变得困难,这种做法就应该被认定为是不合适的。如果提交历史一团糟,这个一团糟到底是改善了软件开发环境,还是影响了软件开发环境,你这样去判断,就能知道保留一团糟的历史是否是一件正确的事情。不要为了准确而准确,为了记录而记录,这是一个软件开发工具,不是史书编撰工具。
17 天前
回复了 hanxu317138 创建的主题 git git rebase 那么重要么???
@dcsuibian #19
这两种观点并不是完全冲突的。
保留历史的细节程度和历史的尺度有关。比如说你遇到了生产事故,需要写事故处理记录,你当然要把每一分每一秒每一次事件都记录下来。但如果你是在写上下五千年的史书,那会有人关心你某一天下午 2 点的时候打翻了一杯水吗。
我司在开发的比较大的项目,尺度基本是上下十年,一个工程师一个月交两个功能,一个 team 下 50 个人一个月就是 100 个功能,一年 1200 个,十年 12000 个,假如平均实现一个功能有 10 个提交,那就是 12 万个提交,你光是要查两三个月前某个提交的 bug 就得翻不知道多少页才能找到,就非常不方便。这还是 master 分支,你要再加上 release 分支测试分支就更多了。所以我们要求所有合并到主线的提交都是 squash merge 。开发分支提 PR 的时候随便你多少个提交,最后全合一起。
如果是小项目,比如说 one man 项目或者一个 team 里两三个人协作,那可以把提交做得细一点,合并 feature 分支的时候用 merge commit 就没问题。

记录实际发生过什么这个也是有粒度的。严格来讲,每一次输入删除都是一次更改,但你肯定不会觉得每打一个单词都要提交吧。那么到底打多少个单词才需要提交一次呢,删了多少代码才需要提交一次呢。这个粒度把控,不同的人也有不同的观点的。
17 天前
回复了 hanxu317138 创建的主题 git git rebase 那么重要么???
先 squash 再 rebase 再 merge 就行。
每一个操作都有自己该用和不该用的场景,正确的做法是在正确的场景用正确的操作。
1  2  3  4  5  6  7  8  9  10 ... 1023  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5221 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 165ms · UTC 07:17 · PVG 15:17 · LAX 23:17 · JFK 02:17
Developed with CodeLauncher
♥ Do have faith in what you're doing.