V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  mrzx  ›  全部回复第 13 页 / 共 56 页
回复总数  1106
1 ... 9  10  11  12  13  14  15  16  17  18 ... 56  
2023-01-18 15:43:04 +08:00
回复了 zero47 创建的主题 程序员 新 MacBook Pro 16 寸起售 2W, SSD 才 512G
我到现在还在用 2012 的 mac mini 做服务器+电视机 airplay 投屏器+机顶盒
2023-01-18 15:22:22 +08:00
回复了 RedBeanIce 创建的主题 宽带症候群 [100 米网络问题]
@kingsoT 主要是 UP 的需求对网络要求比较高,尤其是 lol 这种网战游戏,别说延迟高有影响了,丢包更是不允许,影响战局。


如果只是单纯的浏览网页,看电影这种需求,即使是采用无线方案,控制在一定范围的丢包率,那也是可行的。延迟高,丢包对这种应用没有太大影响的。
2023-01-18 14:52:56 +08:00
回复了 RedBeanIce 创建的主题 宽带症候群 [100 米网络问题]
@FabricPath 怎么会,你也对无线太自信了。你接过多少私活,部署过几次类似的长距离无线项目?有过多少次实施经验?

下雨天,雾天,雪天,对无线都有影响的,而且尤其是下大雨的时候,铁定丢包
2023-01-18 14:45:30 +08:00
回复了 Tounea 创建的主题 程序员 各位对个人电脑安全做到什么程度了?
@Tounea 你们公司 IT 水平太渣了。。而且估计是 IT 部门在公司地位太低了,被当成了服务为主的部门。。
2023-01-18 14:41:49 +08:00
回复了 linuxgo 创建的主题 宽带症候群 最近开始玩 ros,也顺便做点贡献
@xsourse 是的啊,你多拨,不就有多个公网 IP 了吗
2023-01-18 13:44:18 +08:00
回复了 RedBeanIce 创建的主题 宽带症候群 [100 米网络问题]
拉光纤最实际(最少双芯,一收一发,别搞运营商那套单芯,xpon/olt/onu,那是为了节省线缆资源的替代技术)。

无线一定肯定是小白最想推荐的。。但其实一旦是下雨天,下雪天,不丢包就不错了。。更别说延迟低打游戏的问题了

拉光纤最大的问题是熔纤,故意打 10000 号报故障,然后约个宽带师傅,给点钱帮你搞定了。

有条件上铠装光纤(铠装最低 4 芯起),汽车压都压不坏,不过宽带师傅的光纤熔接机不太好熔。。。
没条件就买 2 跟单芯皮揽光纤,外面在包一层,这种任何机器都好熔。。

100 米以上别考虑双绞线了。。。不靠谱。。

哦,最好直接到位用单模光纤,一步到位(仅仅是光模块,收发器贵些) 别用多模,多模几年一个新规格( om1,om2,om3,om4,om5 等等,未来估计还会有新的)。。。

网络设备(路由器 /交换机----双绞线---A 屋光纤收发器-----单模光纤----B 屋光纤收发器--双绞线--B 屋网络设备(路由器 /交换机)
2023-01-18 10:24:07 +08:00
回复了 Tounea 创建的主题 程序员 各位对个人电脑安全做到什么程度了?
@ReZer0 你以为我们运维部门是吃干饭的?。。。。我们公司就抓到一个。。结果去上门拍照的时候,被他同事发觉告密给他了。。。本想第 2 天上公司公告的,没想到他吓得当天晚上凌晨跑回公司,把 frp 删除。。

你真以为程序员想的小心思,我们都不知道?有太多技术可以监控你们的电脑及分析网络流量

其实本来是想拿他当出头鸟,警告公司所有人的。。。后来看他态度良好,此事就算了。。不然他肯定立刻毕业了。。
@muhairen 128G

在补充一句,跑 zfs 一定要 ecc 或者 recc,为什么,自行谷歌吧
UP 主是不是放错区了?这边是宽带症候群,不是 NAS 区
最多找个 ssd 开个 log..

还是增加内存 收益最大。。。

自组 NAS ,最好考虑服务器主板,这样会有比较多的内存槽位。ddr4 最大的是单根 32G 一根。还是多考虑下以后扩容内存的事吧。。。。
可以参考这篇文章
https://www.a-programmer.top/2021/10/15/ZFS%E7%B3%BB%E5%88%97%EF%BC%88%E4%B9%9D%EF%BC%89%E5%8E%8B%E7%BC%A9%E4%B8%8E%E6%95%B0%E6%8D%AE%E5%8E%BB%E9%87%8D/

数据去重( Deduplication ,重复数据删除 /重删)
我们还有另一种与压缩相结合的方法来节约磁盘空间,那就是重复数据删除。现在,有三种主要的重复数据删除类型:文件、块和字节。文件重复数据删除是性能最高、系统资源成本最低的。每个文件都使用加密哈希算法进行哈希,比如 SHA-256 。如果哈希值匹配多个文件,则不将新文件存储在磁盘上,而是在元数据中引用原始文件。这可以节省大量空间,但也有一个严重的缺点。如果文件中的单个字节发生了变化,哈希值将不再匹配,这意味着我们不能再在文件系统元数据中引用整个文件。因此,我们必须将磁盘所有块做一个复本,对于大文件,这对性能有很大的影响。

另一种极端情况是字节重复数据删除,这种重复数据删除方法成本最高,因为您必须保留“锚点”,以确定重复数据删除和唯一字节区域的开始和结束位置。毕竟,字节就是字节,是不知道哪些文件需要它们,它只不过是一个数据的海洋。这种重复数据删除技术适用于文件可能被存储多次的存储,即使文件没有在相同的块下对齐,比如邮件附件。

块重复数据删除处于三者中间位置。ZFS 仅支持块重复数据删除。块重删共享文件中所有相同的块。这允许我们只在磁盘上存储唯一的块,并在 RAM 中引用共享块。它比字节重复数据删除更高效,比文件重复数据删除更灵活。然而,它有一个缺点——它需要大量的内存来记录哪些块是共享的,哪些不是。不过,因为文件系统读写数据是以块的方式,所以对现代文件系统使用块重复数据删除是最有意义的。

共享块被存储在所谓的“重复数据删除表”中,文件系统上重复的块越多,这个表就越大。每次写入或读取数据时,重复数据删除表都会被引用。这意味着您希望将整个重复数据删除表保存在快速 RAM 中。如果您没有足够的 RAM ,那么表将溢出到磁盘上。这可能会对存储的性能产生巨大的影响,无论是读数据还是写数据。


数据去重的开销
所以这还有个问题:你需要多少内存来存储你的重复数据删除表?这个问题没有一个简单的答案,但是我们可以对如何处理这个问题有一个很好的总体思路。首先,查看存储池中的块数量。你可以看到这个信息,用如下的命令(耐心点-在它给出报告之前,可能需要一段时间来扫描文件系统中的所有块):

# zdb -b rpool

Traversing all blocks to verify nothing leaked ...

No leaks (block sum matches space maps exactly)

bp count: 288674
bp logical: 34801465856 avg: 120556
bp physical: 30886096384 avg: 106992 compression: 1.13
bp allocated: 31092428800 avg: 107707 compression: 1.12
bp deduped: 0 ref>1: 0 deduplication: 1.00
SPA allocated: 31092244480 used: 13.53%


在本例中,存储池“rpool”中有 288674 块被使用(查看“bp count”)。池中的每个重复数据删除块需要大约 320 字节的内存。因此,对于 288674 块乘以 320 字节 /块,我们得到大约 92 MB 。文件系统大约有 200 GB 大小,所以我们可以假设重复数据删除只能增长到大约 670 MB ,尽管它只有 13.53%被填满。也就是说,每 1GB 的文件系统需要 3.35 MB 的重复数据删除数据,或者每 1TB 的磁盘需要 3.35 GB 的 RAM 。
@wangyuxian95 去重不要开,不然最少内存 double ,建议 x4. 及其消耗内存

@muhairen 磁盘总的 block 大小

zfs 之所以性能有很好的表现,背后都是超多的内存支持着的。。。
低内存想用 zfs,还想性能好?还是打消这个念头吧。。。
2023-01-17 12:10:43 +08:00
回复了 Chaconne 创建的主题 程序员 qq 邮箱是没人维护了?
@c0t 对啊,现在你们知道为什么开二次验证了吧?
2023-01-17 11:56:19 +08:00
回复了 Chaconne 创建的主题 程序员 qq 邮箱是没人维护了?
你们不知道腾讯的邮箱数据和网易的邮箱用户数据,早被人扒了个干净了吗?拖库几次了你们都不知道。。。

现在暗网里,所有网易邮箱的用户数据从十几万元的价格,降到现在免费下载。。。

你们是不是习惯所有邮箱都一个密码?没事黑别人,我们就喜欢拿网易邮箱数据搜搜,看看有没有人的密码,然后尝试。撞库这种几乎没有任何技术含量
2023-01-17 11:40:48 +08:00
回复了 linuxgo 创建的主题 宽带症候群 最近开始玩 ros,也顺便做点贡献
@gy6221
@xsourse
https://www.77bx.com/46.html
试试这个?


RouterOS (以下简称 ROS )对于 NAT 类型设置不像爱快 iKuai ,OpenWrt/Lede 一样有直接的设置可以直接设置成 FULLCONE NAT ( NAT1 ),至于为什么要设置成 NAT1 呢,大部分是现在流行的挂机的要求。其实对于 ROS 来说,要实现 NAT1 对于了解 ROS 和 NAT 类型的高手来说非常简单。


完全圆锥形 NAT ( FullCone NAT 、NAT1 )

所有来自相同内部 IP 地址和端口的请求均被映射到相同的外部 IP 地址和端口,当映射关系建立之后,任意外部主机均可随时通过外部 IP 地址和端口向内部主机发送 UDP 报文,由于对外部请求的来源无任何限制,因此这种方式虽然足够简单但却不那么安全。


ROS 配置

1 、基本的上网配置,pppoe 设置,masquerade 上网设置等等,这边就不详细介绍了,请看我以前的文章

.................................
2023-01-17 11:39:08 +08:00
回复了 linuxgo 创建的主题 宽带症候群 最近开始玩 ros,也顺便做点贡献
@xsourse
@gy6221

你们说的是完全锥型 NAT ( Full Cone NAT ,后面简称 FC )?
2023-01-17 11:33:28 +08:00
回复了 linuxgo 创建的主题 宽带症候群 最近开始玩 ros,也顺便做点贡献
@fastcache 7.x bug 一堆,而且说是稳定版,我看跟开发版差不多的质量。

用老版本 6.x 吧,稳定一些,等 7.x 出长期支持版的时候在升级。

@sp670 给 routeros 一些时间吧,你看他们 wifi6 的产品都晚别人很多年了。。wifi5 的还没完全调试完毕。

我家里现在用的都是 ubnt 的 wifi5 产品,等 routeros 成熟了,我打算全部换 mikrotik 的 wifi 的产品.早期我做私活的时候,为客户优化漫游范围,搞死我了,capsman 很弱智,只能单纯的凭信号强度来做是否切换的判定标准,明明客户在 3 楼别墅了,还腻在 2 楼的无线 ap 上(正常情况应该连 3 楼的 ap ),最后只能反复调整 2.4G 的信号功率和覆盖范围( 2.4G 穿墙好有时并不是好事)。并且优先让客户的客户端接入 5G
你们不知道,很多 app 利用加速度传感器录音吗?即使你没有开麦克风权限。。。

真羡慕 android 平台,已经开始对各类传感器也有严格的权限开关了。。。

IOS 还不知道什么时候会有。


摇一摇只是利用了“国家禁止 app 乱弹广告”方案的一种规避手段。不过在 2022 年年底,国家刚针对摇一摇做出一些限制。
2023-01-16 17:14:55 +08:00
回复了 cxytz01 创建的主题 程序员 工作十几年的一线老码农,老板让转管理,是否该转?
小公司,有什么管理岗?明明就是想让你承担更多的活,并且分离你最核心的价值

再说,最关键的一句话 “系统掌握在我手里” 人家老板明明想剥夺你最有价值的东西。。。。


以前的程序员为什么牛?那是因为早期产品都是 1~2 个人开发的。。你走了,这产品谁也接不了。。数据库,架构,系统,前端,后端,你全部要接触。除非产品寿命周期到了,不然老板开除你都要三思。。。。


现在资本家讲究效率和可替换性,以前一个人要开发 100 天的东西,资本家希望 100 人就开发 1 天(虽然现实比这更复杂),那 100 个人里,每个人就变相做了螺丝钉,你只开发了其中某一个模块,根本不熟悉整个产品逻辑架构,整体是如何开发的?你要是哪天不干了,对产品的影响都是最小的。。因为是螺丝钉吗,替换成本低。。

要分工,要细化,要敏捷性开发,现在成天聊这些?本质意义是什么?


入这行,本来就要不断的学习,干到老,学到老。。。。。哪个行业不是这样的?
要清楚意识到你对公司的最大价值是什么?

虽然说人人都能被替换,但是每个人的替换成本是不一样的,要让老板感到肉痛的才行。。。
2023-01-16 17:04:24 +08:00
回复了 cxytz01 创建的主题 程序员 工作十几年的一线老码农,老板让转管理,是否该转?
@ytmsdy 哈哈,看来你没做过管理,只要做纯管理超过 2 年,你技术早跟不上了。。。温水煮青蛙,你自己都不知道什么时候就不能蹦跶了。。。到时候进退两难,任老板拿捏。

做这样,就得要不断的学习。。。你觉得 linus 就不学习新的知识点和新架构了?
只是中国现在对 35 岁年纪大的不友好罢了。。。。
1 ... 9  10  11  12  13  14  15  16  17  18 ... 56  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   907 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 75ms · UTC 22:23 · PVG 06:23 · LAX 15:23 · JFK 18:23
Developed with CodeLauncher
♥ Do have faith in what you're doing.