V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  yanqiyu  ›  全部回复第 4 页 / 共 36 页
回复总数  714
1  2  3  4  5  6  7  8  9  10 ... 36  
我手里的拯救者和 thinkbook 都可以(理论上 ideapad_acpi 可用的机器应该都可以?)
echo 1 | sudo tee /sys/bus/platform/drivers/ideapad_acpi/VPC2004:00/conservation_mode
开限制充电点亮
243 天前
回复了 kkocdko 创建的主题 Linux Linux 笔电的所谓省电技巧
个人体验,现代的轻薄本(没有独立显卡)+足够新的内核和系统软件续航是完全不虚的。

至于为什么会出现 ubuntu 费电的印象了,大多数人装的老 LTS 可能内核就不够新,导致耗电增加。
是不是程序已经释放+重新打开了,要不去对应的 /proc/pid/fd/N 来 truncate 以下
https://github.com/containers/podman/blob/main/docs/source/markdown/podmansh.1.md

podmansh ,用容器替代登录 shell ,就可以只暴露特定功能了
Cockpit 有个 firewalld 的简单的前端,至少开放服务/端口,设置网卡和源的 zone 之类的简单的工作可以完成。

https://cockpit-project.org/guide/latest/feature-firewall

#2 > 比如我一直搞不清楚的一个地方就是 ubuntu 的防火墙到底是用 ufw 管还是 iptables 管

一般而言各种防火墙管理都是生成 nftables 或者 iptables 规则的,也就是说它们只是在帮你管理这些规则(附带比如网络情况变化的自动更新,另外就算是 iptables 规则在一些情况下其实也是翻译成了 nftables 规则)

可能你能自己写裸的规则,但是就要注意不要和这些工具的规则冲突。另外也得看看需不需要采取动作避免防火墙软件更新防火墙的时候给你的规则干掉了
@BeiChuanAlex 这和汇编没关系,虚拟地址分配,虚拟地址到物理地址的映射和 segmentation fault 都发生在 mmu 和 OS 内部,对你的程序是透明的
@llh880808 #3
> 每一个应用都会分配到整个物理内存大小的虚拟内存
并不准确,分配的空间大小和物理内存大小没关系。精简点的程序的用户地址空间甚至可能就只有程序和动态库的映射+自己的栈,花哨点的可以上来就要 TB 量级的匿名 mmap 自己分配。

> 使用更高特权等级(默认的 user 等级应该是无权访问的),查询 PMP 相关配置可以拿到内存地址的读写权限
其实可以读自己的 maps 文件/smaps 文件来查询(怎么看怎么不清真)
或者想办法直接干了然后捕获 SIGSEGV 就知道是不是可读可写了...
@M2K4 其实"微软那套安装"也可以部署一个带应用的镜像,不过只是大家习惯了倒腾 ghost 于是就没人折腾。
@fox0001 我又不是装过 98/95 ,这两个甚至 Windows 可以不在 Windows ,全新安装清理一下原来的 Windows 和 DOS 的几个配置文件就行。

2000/XP 的安装器我记得不支持 Windows.old ,但是把旧的 Windows 删了他也不会教你格式化

大概 win7 还是 8 开始就支持 Windows.old 了

真的会让人丢数据的 ghost ,可以说这个备份还原工具影响深远....
#71: 只要你显式要求格式化,安装过程不会删除你的任何文件 -> 只要你不显式要求格式化,安装过程不会删除你的任何文件
@feikaras 只要你显式要求格式化,安装过程不会删除你的任何文件。就算 Windows 清理旧的状态的机制会有问题,你完全可以手动移动走所有系统文件再执行全新安装。

真要说历史遗留导致爱分区那大概是 ghost 的 XP/Win7 盛行的年代,ghost 倒是不支持保留文件。

> 覆盖安装大部分时候不会修复问题

举个例子,覆盖安装不会继承所有配置和系统文件,用户数据也是全新的,除了中病毒了导致系统盘充满病毒,以及实质上的文件系统损坏之外我想不到出问题的可能性。
@fox0001 为什么前提是重装系统会丢数据,直接安装盘重装旧的文件全部都会进 windows.old ,会丢什么?
289 天前
回复了 wakaka 创建的主题 Android 小米 14pro 如何升级 google play version?
居然小米商店就能更新,之前一直都是手动去 apkmirror 下载之后 adb 安装的
291 天前
回复了 livin2 创建的主题 Linux Linux DE 与普通消费市场的距离到底在哪?
@twl007 #87
> 驱动部分 我们只讨论桌面的 默认面向一般用户的 其实 gpu 驱动已经够一般用户喝一壶的了 其他的驱动包括打印机 复印机扫描仪 相机 这些 Linux 上面的支持远不如 Windows

要是 amd/intel ,不是非常新的设备,其实完全能用。

打印机我只用过 IPP 之类的东西所以没折腾过传统打印机驱动。但是 Linux 和 MacOS 在打印机方面都是一个档次的支持?都是 CUPS 。

Webcam 和无线网卡也一样,说实话还没买到不能开箱即用的型号。

不过反过来,多数 Linux 发行版有 libldac 的 LDAC 支持和 libaptx 的 aptx 支持,但是在 Windows/MacOS 上就很难折腾这东西(记得有要钱的商业方案)

> [...] 阵列卡开箱即用你还真的错了 除了 redhat 以外 就算 Ubuntu 都保证不了开箱即用 我就遇到过某厂商只提供 redhat 不给 ubuntu ?驱动的设备

那大概是我一直用 Fedora ,和 RedHat 亲缘很近罢,不过买阵列卡的时候看看内核`drivers/scsi`或者顺便打听下有没有主线支持就能避坑了,要是有主线支持就完全不用管厂商给的驱动了。
291 天前
回复了 livin2 创建的主题 Linux Linux DE 与普通消费市场的距离到底在哪?
@twl007 #77 windows 的回滚是基于 WinSxS 之类的机制,Linux 这边也有做的更彻底的,比如基于 ostree 的系统(Fedora Silverblue/Steam Deck)。允许单个分区内同时存在多个完整的系统,回滚系统就是简单的选择启动项(并且更新/回滚不会在关机/重启时 hold 半天,整个过程也不会有“请不要关闭电源”的脆弱时期。)

#75 > Linux 上面驱动支持除了几个企业发行版 其他的都没有啥驱动支持
除了显卡这东西涉及复杂的封闭实现,(尤其是 NVIDIA ,但是 NVIDIA 的现状确实正在好转)。其他情况下硬件支持 Linux 并不差,要是涉及万兆网卡或者阵列卡之类的东西一般 Linux 支持更开箱即用。(我在 windows 上是遇到过“需要联网以下载 x550 驱动”这种事情的),但是在 linux 上内核开箱一般就有 ixgbe 搞定一切问题了

@iminto #4 > 我有一百种方式玩死 Linux ,我随便改个配置或删个文件就能搞挂,出一些莫名其妙的问题。我就不敢让小孩乱动我的 Linux 系统。

不给小孩权限,我还更放心给他玩 Linux ,至少他从奇怪的网站下载下来能提权的病毒的概率还会减小不少。如果给权限 Windows 更不靠谱,因为微软不怎么在意 admin 绕过 UAC 的问题。(虽然 Linux 上给 wheel 用户不可信的二进制折腾能干的事情也不少)

> 而 Windows 不一样,windows 的 admin 用户不是最高权限,最高权限是 system 权限,对系统有较强保护。

正如 wheel 组输一次密码就变成不受限的 root 一样,Windows 的一个 UAC 弹窗也能给你 system/TrustedInstaller 权限(nsudo),只是一般程序没这么要权限。实际上 Linux 上 polkit 提供的提权更加细粒度化,在提权确认窗口还能看见当前请求究竟是为了什么 action 安排的。
@ukhack #2 > BT 之类的正常业务就废了

BT 你手动给端口映射就行
295 天前
回复了 xyj998 创建的主题 微信 微信要出真正能用的 Linux 版了?
因为伪装 uos 要放一个硬编码路径的文件于是不容易 flatpak (需要打运行时/魔改)
于是干脆用 bash 脚本糊了一个散装 flatpak ( xdg-dbus-proxy+只挂载有必要的路径)
至少能用
297 天前
回复了 Dffcc 创建的主题 Linux yum 进程锁定
@fuis
@Still4
至少 yum-3.4.3-168.el7.centos.noarch 是能正确处理 sigint 的,所以留了个 pid 文件大概是别的原因

#6 > 可能是因为有其他锁的存在
问题不是锁,问题是判断锁是否有效的机制太简单了,就是看看 pid 文件里面的 pid 是不是对应正在运行的进程,这东西容易出现巧合。
要是一开始就用锁反倒不会出现重启之后还不能 yum 的问题( flock 之类的肯定重启就释放了)
297 天前
回复了 Dffcc 创建的主题 Linux yum 进程锁定
> 为甚麽按 ctrl+c 跟 ctrl+z ,无法解除 yum 进程锁定
理论上 yum 退出会正确的清理 pid 文件才对(但是是 sigkill/断电/crash 掉了的情况 yum 肯定没机会清理),就算没能清理,下一个 yum 启动的时候也会检查对应的 pid 是否是正在运行的进程,如果 pid 对应正在运行的进程就会等它退出。

所以出问题的情况就是 yum 没正常退出导致 pid 文件没清理( bug ),然后 pid 文件记载的 pid 恰好被别的进程用了,判断逻辑搞不清楚究竟是不是有正在进行的事务于是放弃了(巧合)。

> 有甚么方法可避免 yum 进程锁定的发生?
改源码,做掉整个 lock 机制然后责任自负(同时两个包管理同时跑可能把系统或者包管理元数据搞坏,这个 lock 就是保证用户不能这么干)
或者给它改成用 flock 这样的机制来锁,这样子就会避免 pid 回收/恰好重启后 pid 被用了的巧合

其实我很好奇为什么 yum 不一开始就用 flock 之类的东西来做锁...
1  2  3  4  5  6  7  8  9  10 ... 36  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2833 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 28ms · UTC 11:29 · PVG 19:29 · LAX 03:29 · JFK 06:29
Developed with CodeLauncher
♥ Do have faith in what you're doing.