V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ranaanna  ›  全部回复第 3 页 / 共 20 页
回复总数  386
1  2  3  4  5  6  7  8  9  10 ... 20  
@Citrus 这逻辑,腾讯云有被 gfw 吗,可比性在哪里。意思是只要被内企撸一把羊毛就合规了?
可不可以向有关部门举报 cloudflare ,因为“任何单位和个人不得自行建立或者使用其他信道进行国际联网”?有没有 ISP/ICP 经营许可证?被封的同时又“合规翻墙”,凭什么
130 天前
回复了 frostashe 创建的主题 macOS 科研狗被 mac 版 office 劝退
@Muist 这是对位图的要求,如果是图像和照片,300dpi 可以经得起一定程度的缩放,是硬拷贝的起步要求。tiff 基本无损且适合硬拷贝,当然是出版社的推荐。但是,现在看很多文章的图,明明应该是矢量的线条和文字,却有明显的 scaling artifacts ,完全经不起缩放,就有今不如昔每况愈下的痛惜感。这种情况就是“课题组”的头儿的锅
@zzrot19910319 @lijiachang #4 完全同意。顺便说一句,那些无线、蓝牙、now playing 之类的,也可以隐藏掉。在旁边的 control center 中都有,不隐藏掉也是重复。另外,隐藏 spotlight 完全正常,没有复现 OP 的问题
@wniming #3 这个回答并不相关。这个-Z 是指定以后在这个池中配置新的精简逻辑卷时,先用零擦除相应的底层存储空间,因此显然会影响 thin provision 的速度(特别是对于大卷),但可以保证数据完整性,避免因为残留的数据出现问题。这无关数据泄露。一般是建议不要禁掉,如果已经禁掉用 lvchange -Z y 即可恢复。只要不是经常新建逻辑卷其实完全无关紧要,并且完全不会影响虚拟机性能。后面的问题是这个道理
这还不简单,它的 warning 已经很明确告诉了呀,or ,也就是要么保持大的 chunk size 但 disable zeroing ,要么用小的 chunk size 但保持 pool zeroing

建议是后者,因为 1. OP 将来又不会扩展到 508.01 TiB ,2. 提高空间利用率,3. 只是一个 2 TiB 的卷,何必选这么大的块大小,说实话 128 KiB 都已经足够,对性能影响微乎其微
130 天前
回复了 frostashe 创建的主题 macOS 科研狗被 mac 版 office 劝退
@Muist 当然,因为可以运行脚本 office 关闭了 eps 的支持,替代品是 svg 和 emf ,但前者矢量后者小众,总之不完美
130 天前
回复了 frostashe 创建的主题 macOS 科研狗被 mac 版 office 劝退
@Muist 用 tif 之类的位图格式不是好主意,应该用 eps ,预览位图输出矢量才是王道
130 天前
回复了 frostashe 创建的主题 macOS 科研狗被 mac 版 office 劝退
mathtype 专有软件功能简单收费又贵,20 年前就已经是老古董了,之后有段时间因为推出免费版本(记得叫 texaide?,可以作为 latex 公式 wysiwyg 编辑器)顺带着复活过,后来被 wiris 收购回归收费还改得不好用就基本上玩完了。没想到直到现今还有人在用,感觉国内科研界很多人喜欢停留在老旧软件?
另一个类似的软件似乎是 originlab 的 origin
138 天前
回复了 jsq2627 创建的主题 宽带症候群 记 QUIC 的折腾记录
@jsq2627 逻辑上不是同一件事。connection id 就是为了解决诸如 nat rebinding 发生时保持连接的问题,正如 OP 所说是 quic 的“一大特性”,但即使这样,还会有服务器地址 anycasting 的问题,需要服务器端做出改变,与客户端没有关系
138 天前
回复了 jsq2627 创建的主题 宽带症候群 记 QUIC 的折腾记录
@playboy0 也只能表示没看懂。如果是因为问题一,那么应该是选择好的 vps 、机场以及梯子,何况前面已经说到有明显的“感受”,如果是因为问题二,那么禁不禁用没啥差别,问题三似乎是因为 cloudflare 目前不能很好处理 quic 连接 anycasting 的问题,并不是 OP 理解的 NAT 重绑定的“支持”问题,相信会很快解决。所以,似乎没有禁用 quic 的必要性
140 天前
回复了 ST0RMTR00PER 创建的主题 macOS macos Sequoia 15.4 中 chronod 一直占用 100%+ CPU
@ST0RMTR00PER 又看了一下,更新重启(两部分别是整一天前和 2 小时前)后目前的 chronod 的%CPU 虽然都为 0 ,但 CPU time 却高到排至第三位(排在 google chrome 和 identityserviced 之后),说明曾经高过。所以是否是需要耐心等待一段时间,等它完成特定任务后说不定会恢复正常?
141 天前
回复了 ST0RMTR00PER 创建的主题 macOS macos Sequoia 15.4 中 chronod 一直占用 100%+ CPU
第二个 notification center 的 cpu 也有点高,这个和 chronod 一样也和 widgets 有关。是不是启用了某种不同寻常的 widgets (例如 ios 的 widgets ?),在数据同步时导致“大量的对象和数据传输操作”?

看了一下这两个的%cpu 均为 0
149 天前
回复了 abbb 创建的主题 Linux 请求帮忙装个论坛
@abbb 说实话,这个作者实在是太不上心了:niginx 配置文件是/etc/nginx/nginx.conf ,不是 nginx.cong 。这么明显的 typo ,还特地加了 bold ,这么多年都没有改一下。这个很可能误导了 OP 导致了失败(因为其他的下载解压缩文件和 systemd 配置已经简单到不可能搞不定了)。但是考虑到论坛的样式那么古早,再加上古早的 centos 7 ,建议 OP 还是放弃吧,1 不值得折腾这个,2 即使成功安装也是失败
@raysonx 非常感谢! OP 真是及时雨。本来 ipv6 是用 HE tunnel broker 一直没有问题,正好今天想试试国内流量不走隧道,结果就,百思不解的时候正好看到 OP 的帖子,完美解决
163 天前
回复了 chevalier 创建的主题 macOS Chrome 开始在 macOS 启动台拉屎了?
似乎也不算太糟糕吧,当然也没有用就是了。说实话 launchpad 都基本上没用过

如果实在很强迫,只要把~/Applications/Chrome Apps 文件夹中的内容移到 Trash 就干掉了

@AoEiuV020JP 9 0 貌似是 Google Chrome.app 自身的权限问题,因此需要每次只能用新的手工替换。是不是终端 sudo chown -R root:wheel /Applications/Google\ Chrome.app 可以解决?
164 天前
回复了 han654 创建的主题 macOS macOS 连续输错 33 次开机密码还没被锁定!?
@Chaidu 这逻辑。请参见 @Pazakui1259 。人家就是这么设计的,“为了帮助防止恶意软件通过尝试攻击用户密码而导致永久数据丢失”,不是“只要想办法让这个恶意软件别把 OP 的 Mac 锁定就好”。mac 被锁定(严格地说,是 disabled )可是很严重的事情,一旦发生就只能进入恢复模式抹除硬盘数据重置电脑,如果没有备份这个过程会导致“永久数据丢失”,进一步地,如果这个时候再输错密码 10 次又没有设置 icloud Find My ,那么 OP 的 Mac 就基本等同报废了
164 天前
回复了 han654 创建的主题 macOS macOS 连续输错 33 次开机密码还没被锁定!?
mac 只是在开机启动后的登录窗口有 10 次的密码输入限制和延迟,10 次之后进入恢复模式还有 10 次。一旦成功登录,之后的退出屏保、亮屏以及睡眠唤醒的登录界面就都没有次数限制了。这是为了防止熊孩子以及恶意软件故意输错密码让 OP 的 mac 锁定
抱歉查了一下确实休眠(深度睡眠)时通过键盘鼠标能唤醒,并没有断电,本身就设计成这样,应该是没有办法了
休眠本来就会停止供电,要做的是把默认睡眠( hibernatemode 0 )改成休眠:
pmset -a hibernatemode 25

但是,能否接受每次唤醒都要抬起按电源按钮?
1  2  3  4  5  6  7  8  9  10 ... 20  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1030 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 22:47 · PVG 06:47 · LAX 15:47 · JFK 18:47
Developed with CodeLauncher
♥ Do have faith in what you're doing.